TOPIC: AccessNav
#165
AccessNav 4 Years, 4 Months ago
Hello Jos,

Thanks for the excellent AccessNavControl!Few suggestions, doubts, problems...

1)When AccessNav is started with an empty table,the window shows only one big field. It is corrected as soon as the window is resized / maximised.
2)The fields that derive from ChooseField (those with a drop down arrow) are not drawn correctly when they are placed over the "No Data available" message shown when the table is empty. The area over the message is not visible.
3)With an empty table if I press New and then Cancel, an error message that says uninitiallized member - # BorderControl_x is shown. This dissappears if the Cancel button is pressed again.
4)With an empty table the "No Data" message si shown. This does not disappear when you press New. It is visible beneath the big field that comes up and also beneath all teh fields that appear after resizing the window.
5)After pressing Cancel (after pressing New button), if the window is maximized the "No Data" message is drawn twice.
6)When we switch to edit mode (especially when persistent is switched) the navigator should be working. It is not.
7)Where actually is the field where we can type to locate fast? I tried the place below the navigator without sucess.
8)The strip that carries the buttons should be coloured differently to differentiate from the form area.Even a line above the buttons is sufficient. This is especially true when the Edit mode is switched on.
9)An option to turn off Global and Current menu buttons would be great.
10) I got an error saying uninitiallized member: AccesNAvControl_record On_Delete() method while trying to use the Delete button.This happens when a single record with an empty keyfield has been saved and delete is attempted. If such a record has beeen saved and AccesNAv restarted it does not show the record, but the Edit button is active. If I press the Edit button, uninitiallized memeber: AccessNavControl_keyquery from checkdeleted() method is thrown.

Once again thanks,
ajith
 
 
#168
Re:AccessNav 4 Years, 4 Months ago
Hi Ajith,

Glad you like it. We discussed this one some time ago and you should find most of your suggestions implemented. I only had to drop it for a long time due to lack of time.

Most problems you mentioned were caused by the "No data Available" control. I added it in to clearify that indeed no data is available and not just an empty entry form. Also when using dynamicTypes, no form could be shown cause no type is choosen yet. Only constructing and destroying the control were still based upon a previous method of dealing with this.

6)When we switch to edit mode (especially when persistent is switched) the navigator should be working. It is not.

At first I thought this would be simple by adding
if (.Send("EditMode?") and .Send("Dirty?))
.SetEnabled(false)
to AccessNavListControl.MOUSEMOVE()
and adding
if (mode isnt 'Edit')
just before
EnableWindow(.Controller.Vert.Split.AccessNavList.Hwnd, false)
in AccessNavEdit.StartEditMode()

So the navigator wouldn't be disabled in edit mode. Only if changes where made to the current record, it would be disabled and I would have to revert this the
moment the record is saved.
But there's more to consider: the navigation keys (Up/Down..) are also disabled when a record can be edited. The record is locked, needs to be unlocked and the new selected one requires locking...
So I let it be for now.

7)Where actually is the field where we can type to locate fast? I tried the place below the navigator without sucess.
No field, if the navigator has focus and the key is of type string, you should be able to type. The place below the navigator is only used to show what's typed in sofar. (It's also reserved for possible extensions as looking for dates, numbers and dealing with composed keys)

8)The strip that carries the buttons should be coloured differently to differentiate from the form area.Even a line above the buttons is sufficient. This is especially true when the Edit mode is switched on.
Added a horizontal etched line.

9)An option to turn off Global and Current menu buttons would be great.
Added checking for 'Global' and 'Current' members in protect:

10) I got an error saying uninitiallized member: ...
Fixed

Attached AccesNav with the changes.

Jos
File Attachment:
File Name: 1e74ae8a4c35b6c463a0416b923eda63.
File Size: 12460
 
 
#169
Re:AccessNav 4 Years, 4 Months ago
The attached file name should be AccessNav.zip. Don't know why it got renamed to some checksum after submitting the message. I try it again...
File Attachment:
File Name: b3ad1c878344cc1e8b348fa50142de44.
File Size: 12460
 
 
#170
Re:AccessNav 4 Years, 4 Months ago
Hi,
Thanks 4 the quick fix! And also for incorporating all the suggestions. As u say the file has not been uploaded properly, so could not check it.
ajith
 
 
#171
Re:AccessNav 4 Years, 4 Months ago
Hi,
The file is there though it is named differently! I will check and let u know,
ajith

Post edited by: ajith, at: 2006/04/15 15:36
 
 
#172
Re:AccessNav 4 Years, 4 Months ago
Hello Jos,

After a quick check, I found all problems solved. Thanks to u. I noticed few problems with protect -

protect: #('opi_middlename' , Delete: "Tell me why")

removes the Delete button.

If i use potect: 'opi_protect' and Rule_opi_protect contains the code - #('opi_middlename' , Delete: "Tell me why"), Delete button is not removed, but on clicking it an alert with the message is shown. If it is Global:, the button is there and it can be clicked. The field is also not protected. Similarly 'allbut' is also not working from inside the rule.

What if I want all fields to be protected and want New or any other button(s) to be removed?

When protect is provided as an object, it should provide field names as string and from inside the rule, it should be provided as members. Shouldn't the disparity be corrected?
ajith

Post edited by: ajith, at: 2006/04/15 17:04

Post edited by: ajith, at: 2006/04/15 17:10
 
 
#173
Re:AccessNav 4 Years, 4 Months ago
Hi Ajith,

The protect: argument given as an object to AccessNav is ment to be somewhat global. It should indeed remove the corresponding buttons and not just disable them or display a message.
Not protecting the fields returned by the rule is also related to the dynamic construction of the controls. Line 18 of AccessNavControl:
.data.SetProtectField(.protectField)
should be moved right after the line:
.data = .edit.GetControl().Data
in SetData()

The object protect: could be extended to provide for an optional rule. So it would also accommondate something like dynamicly protecting (all) fields. But shouldn't protect: then be an object at all times?

The protect: argument as well as the rule have the field names as members?

It wouldn't make much sense to disable the Global button by the protect rule if you could just remove it by using the protect: argument.

I'll put the changes on hold for now.

Thanks for your you extensive feedback, didn't put AccessNav into any pratice myself.

Jos
 
 
#174
Re:AccessNav 4 Years, 4 Months ago
Hi Ajith,

The protect: argument given as an object to AccessNav is ment to be somewhat global. It should indeed remove the corresponding buttons and not just disable them or display a message.
Not protecting the fields returned by the rule is also related to the dynamic construction of the controls. Line 18 of AccessNavControl:
.data.SetProtectField(.protectField)
should be moved right after the line:
.data = .edit.GetControl().Data
in SetData()

The object protect: could be extended to provide for an optional rule. So it would also accommondate something like dynamicly protecting (all) fields. But shouldn't protect: then be an object at all times?

The protect: argument as well as the rule have the field names as members?

It wouldn't make much sense to disable the Global button by the protect rule if you could just remove it by using the protect: argument.

I'll put the changes on hold for now.

Thanks for your you extensive feedback, didn't put AccessNav into any pratice myself.

Jos
 
 
#177
Re:AccessNav 4 Years, 4 Months ago
Hello Jos,
I will try the change you have suggested and let you know.

>>>>
But shouldn't protect: then be an object at all times?
>>>>
Probably yes. But wont it cause problems if the field names given as its member (the fields which are to protected always) and that returned by the rule are different. Should it be that the field names that are members should be protected always and that any further field names returned by rule will be added to the list? Should the option of providing true as an argument to protect be kept? It is very convenient sometimes. But the same functionality is provided by removing Edit and Delete buttons as well.

>>>>>
The protect: argument as well as the rule have the field names as members?
>>>>>
It is just a typing inconsistency. Probably when protect is specified as an object or as rule name it should be members as the practice with the protect rules of Access is to provide member names.

>>>>>
It wouldn't make much sense to disable the Global button by the protect rule if you
could just remove it by using the protect: argument.
>>>>>

What if do not want Global button at all, but has to use the rule form of protect to specify the different fields that are to be protetced based on different conditions?

>>>>>
I'll put the changes on hold for now.
>>>>>
Sure!
 
 
#185
Re:AccessNav 4 Years, 4 Months ago
Hi Ajith,

Probably I wanted to distinguish between fields and functions that have to be protected. But the fields could be given as members. So I would propose to change the use of protect:
1. It’s always an object
2. Fields and functions are given as members
3. It can take one unnamed member, this string defines the protect rule

The presence of a field member will render the field always read-only, independent of an optional rule.
Would it make sense to assign the value of these members to the fields when adding records?

Jos
 
 
#186
Re:AccessNav 4 Years, 4 Months ago
Jos[/quote]

Hello,
I am sorry I may not have understood you correctly -


1. It’s always an object

Yes! I suppose you have decided not to support true as well.

2. Fields and functions are given as members

Function means Global:, New: ...?
If so, yes!

3. It can take one unnamed member, this string defines the protect rule

Fine!


The presence of a field member will render the field always read-only, independent of an optional rule.
Would it make sense to assign the value of these members to the fields when adding records?

You are asking whether the fields protected outside the rule( by specifying as members of the protect object) should remain protected when a new record is added?
If I understood you correctly, yes!

ajith
 
 
#206
Re:AccessNav 4 Years, 3 Months ago
Hello ,
A probable error in AccessNav - I have a Tabs Control with 3 tabs. The second tab carries a browse with a details table. If I click edit button first, then click the second tab with the browse, edit it and quit, everything is ok. If I select the 2nd tab first, then click edit and modify the record and quit - everything seems to be ok till i return the next time -the changes are not saved!
Also, When a record in the browse is deleted the change is not done if i directly click the OK button of AccesNAvEdit. I have to right click the browse and say save all. This happens irrespective of the order in which the tab is selected.
With a single record in AccessNavControl and two key fields. If i click the top portion of the Navigator and change the key, the change does not take place immediatly.
ajith
 
 
#208
Re:AccessNav 4 Years, 3 Months ago
Hi Jos,
Probably I have said earlier that we do not need a Locate field. I think we need one in AccessNav also. The situation I face - I have a table that carries information like NAme, Age, Sex, Employed in..... The key for this field is a hospital number. In a second table (in which i enter the details of medical examination) i enter this hospital number and display the different fields like name, gender.... I want to see the medical examination details of aperson whose name is the only thing i know. I have to search the first AccessNav and then remember / copy the hospitalnumber and then use it in the second AccessNav.
This Locate should accept a query which may be different from that supplied to AccessNav, but should have a field that has values corresponding to the key. The name of this field may be different from that of the key field of the query supplied to the AccessNav proper. This was implemented in AccessControl earlier and probably supported now also.
ajith
 
 
#209
Re:AccessNav 4 Years, 3 Months ago


Post edited by: ajith, at: 2006/05/02 18:24
 
 
#214
Re:AccessNav 4 Years, 3 Months ago
Hi Ajith,

Couldn't you just use the Global - Filter or the AccessGoto method eventually with a plugin?

Jos
 
 
#215
Re:AccessNav 4 Years, 3 Months ago
Hello Jos,
I do not know about plugins. Anyway it is not an important issue at present. I was suggesting a feature, not exactly my need. Filter... also depends on the query supplied to the AccessNav? Further it restricts teh records shown, doesn't it?

BTW, have you seen the post describing teh problems with browse?

ajith
 
 
#218
Re:AccessNav 4 Years, 3 Months ago
Hi Ajith,

With a plugin you could add an entry to the current menu. But that won't be the place where you would like it. Filter indeed extends the supplied query to AccessNav.

An option would be to do something like:
Code:


Window(Controller
{
Controls: (Vert (Horz (Static Name) (Field width:40) (Button Search)) EtchedLine (AccessNav 'suneidoc'))
On_Search(){.Vert.AccessNav.AccessGoto("name", (.Vert.Horz.Field.Get()))}
})


It's very simplified, but you could extend it to fit your needs and this way there's no need to read in the complete (master)table.

Don't think the locate option ever accomondated a different query. Perhaps you were thinking of linkField or KeyControl?

What post do you refer to?

Jos
 
 
#220
Re:AccessNav 4 Years, 3 Months ago
Hello,

I will try your suggestion.
The post I was referring to is in the 2nd page of this thread.
I am not thinking of linkField or KeyControl. The change was made by me. I am not sure whether it was adopted by Suenido. I will check and let you know. May be Jeff will clarify this point.
Filter indeed extends the supplied query to AccessNav.
If the main query is pers_info, it supports only pers_info where field_x is "" ? That is what you meant when you said filter extends the supplied query?
this way there's no need to read in the complete (master)table.
Where is the need to read in the complete master table? May be i didn't convey what i have in my mind correctly :(
ajith

Post edited by: ajith, at: 2006/05/04 17:06

Post edited by: ajith, at: 2006/05/04 17:11
 
 
#222
Re:AccessNav 4 Years, 3 Months ago
Hello Jos,
The AccessControl still has the feature discussed above.
Syntax -
Code:


AccessControl('table' locate:#(mainquery: 'newquery', keys: #('newquery_key')))



AccessGoto may not be the right choice because you have to pin point one record. What I am suggesting is a locate like field below the navigator. The diaolg that comes up when it is clicked should by default use the query supplied to AccessNav and if a seperate query is provided, should use that 'locate_query'. When the search is done it should move the navigator to the record suggested by the search. If more than one record is there it should move to the first of the group [This I had not suggested earlier].
Example - My table in AccessNAv is 'examinations'. The key is examination_number. It also carries a hospital_number.
I want to search the table 'personal_info' (from AccessNAv carrying 'examinations' ) the key for which is hospital_number.
If I search hospital_number contains 1000, the AccessNav should go to the first record of the table 'examinations' that has 1000 as its hospital_number.

Note: I am not asking you to add this feature immediatly. If you do that, it is fine, but I am just asking whether it would be useful.

ajith

Post edited by: ajith, at: 2006/05/04 19:23
 
 
#229
Re:AccessNav 4 Years, 3 Months ago
Hi Ajith,

Missed that post about the Browse/AccesNav problems completely.
To start with the easiest one:
Switching keys indeed isn't reflected if the record keys nor the order in the navigator list were changed by this action. This was caused by a too optimistic optimalisation. With only one record this order of course wasn't changed, fixed it.

When a Browse is started, all the records are read in and it has a static view of the table from that point on. It's unaware of any changes made to the table elsewhere. Only using Save All or closing will save the changes. Browse does check whether the changed record are identical to those read in when it was started.
But AccessNav also has a static view of the table for the records whose keys are listed. One of the things to do was just to overcome this by implementing a timer that will check every 5 seconds or so for changes to the table. The easiest way would probably be to use Database.CurrentSize() and reread the keys in the navigator list and the record in view when the size of the database changes.

Jos
 
 
#231
Re:AccessNav 4 Years, 3 Months ago
Hi Ajith,

Filter extending the query giving to AccessNav means that it's a further restriction to what records are shown.

I was unaware of the option to use a different query in locate:. Checked the user's manual but didn't find any reference to this.
To your suggestion of a locate option in AccesNav: I had the down arrow of the search field in mind, presenting a list of the query to choose from. For now I can't really determine whether such a search of a second table linking to the current one would be something to be built in while you could do the same by some manual code. And perhaps it then should be just one of the keys listed in the navigator, I don't know.

Will post a new version with the discussed changes shortly.

Jos
 
 
#242
New AccessNav 4 Years, 3 Months ago
Hi,

I uploaded a new AccessNav library. The major changes being:

protect option:
Specifying a rule is moved to the first unnamed member of the object so you can combine the two options.
Fields and functions/buttons are given as members
The protect rule wasn't applied properly.

Switching keys didn't update the keylist if the complete keylist with all the keys wasn't changed.

The record in view and the keylist is now updated every second of idle user time while not in edit
mode, so it's aware of external changes.

dynamicTypes: the name of the typeField is given as the first unnamed member.

The filename should be AccessNav.zip. If it is some combination of hex values, yoy have to rename it.

Jos
File Attachment:
File Name: 638f8087decc5e097ca63e835fa4cc56.
File Size: 16796
 
 
#845
Re:New AccessNav 3 Years, 4 Months ago
Hi Andrew,
Iam not sure if this was the latest copy of AccessNav that joshua posted. But I am sure that almost all probelms discussed in this topic were solved and copy of the same was posted in the forum. The latest (Feb 2007) version of Suneido still carries the bugs that were discussed.
ajith
 
 
#846
Re:New AccessNav 3 Years, 4 Months ago
Hi Ajith,

You are right, this version did not get added to stdlib. Sorry about that. I probably missed it because it came while I was traveling. I will add it.

Hmmm ... when I go to download the file I get an error. I will try to contact Jos for a copy of it. Or maybe you or someone else has a copy they can send me?

Post edited by: andrew, at: 2007/04/07 18:02
 
 
andrew