PDA

View Full Version : AutoFind



Tom Murphy
9-Jun-2010, 03:15 AM
Hi DAW

Can you explain why auto finds no longer work with the main table of the grid as per the code below from the cDbCJGridColumn class? Is there any reason why this can't be done in the new grid.




// autofind if an autofind DD and the field is changed. As soon as a succuessful
// autfoind occurs, the field is reset
{ Visibility=Private }
Function DoAutoFind Returns Boolean
:
Get piBindingTable to iFile
Get piBindingColumn to iField
Get Server to hoServer
Get Main_File of hoServer to iMain
// with grids we will not support main file autofind.
If (hoServer and iFile and (iFile<>iMain)) Begin

Russell McDougall
9-Jun-2010, 06:16 AM
I think this relates to my previous post about the lack of a search popup object for searching Grids below the Prompt list level.

If we use the Customer grid in the Grid examples as an example then if sitting on say the customer no field for customer 2 and type 10. It overrides the customer 2 code whereas it is more logical to find customer 10 if it exists and log onto that row. Try it and if you don't remember which customer no is overriden then consider how a user would recover.

I realise in a cCjDbGrid that a prompt list could be displayed to log onto another record but without a search popup they would have to remember to display the prompt list. It is not intuative.

The search objects of the prompt list need moved down the heirarch to the cCjGrid class and above.

I guess the point is the autofind/search is acting on the displayed grid not the record buffer thus searching the displayed grid representing the underlying datasource is the issue.

Perhaps autofind could be tapped into to trigger the search and or search popup.

This is the last major enhancement i would like to see before the Beta is released.

Larry R Pint
9-Jun-2010, 09:09 AM
If entering "10" in the customer number column for customer number 2 wouldsearch for and move the current row to customer number 10, how would you edit customer number 2 to be customer number 10?

Russell McDougall
9-Jun-2010, 02:02 PM
Good point.
This is probably a clearer explanation.

In the case of the customer list where the first field is a unique index:

If 10 already exists that could never happen and the user would want to latch onto 10.

If 10 did not exist the search would not find 10 and allow 2 to be changed providing the code allowed that.

That is what happens in the old grid via the autofind process that Tom is querying.

I believe the above behaviour is required in the new cdbGrid and is missing because of the block on the Autofind.

Secondly because the new grids have Column searching at the cjGrid level by searching the DataSource columns then the Prompt search objects should be moved down to cCjGrid as the public access to this search ability.

In practice the above finding behaviour may be a combination and or column searching or autofind.

John Tuohy
9-Jun-2010, 06:37 PM
Interesting comments. Let's take the autofind one first.

The autofind was disabled on main-file finds because it's weird and it seems like most of the time you don't want that kind of behavior and even when you did - it's weird.

Tom, can I ask how you use this? The user types in a target and then they press some key. What key do they press? Enter? Tab? Up arrow? down arrow? What happens after the auto-find? Does it do an autofind and then do whatever the key does (like move to the next column or row)? That's what the old grids did and it just didn't seem to make much sense. You always ended up in the wrong column (e.g., Tab) or off your target by one value (e.g., up or down arrow). If you had changes in the row they were lost. This all happens because Autofind was not really intended to be used on main files in grids. It becomes an uncontrolled find.

It seems like a more sensible approach is to limit the terminating keys that will do an autofind and the logical keys for that are the find keys. You type your target and press find, you've got your search and you are still in the right column. But if you do it that way, you don't need autofind at all. Either way it's the exact same number of keypresses. Anyway, that's why it's not there.

On a related topic, the new grids have additional Request_Find capabilities. The same argument can be made about using any of the find keys on a main-table field. While it does provide a nice way to refresh your grid and jump to some location, it's kind of odd. It's not what, you expect data-entry grids to do. You use the find keys to find parent records (same with autofind) and in that context it makes sense. With the new grids you can control this. There is a property named peRequestFindMode that determines when Request_find does something. The modes are:

rfmFindAll - find on all fields. This is how the old grids work and is the default for cDbCJGrid.

rfmFindMainOnly - only find on the main-file. Used for jumping around the list. However, if you try to find in a parent field it'll do nothing because it would just change the parent, which is confusing when jumping around.

rfmFindMainSuper - Finds on main files and on parent files that do super-finds (first find the parent and then refind around the main file with its related index). The old dbLists did this and this is the default for cDbCJGridPromptList.

rfmFindNone - no finding and refreshing at all. Sometimes it just gets in the way.

rfmFindParentOnly - Only find on parent fields and do regular parent finds (just change the parent record). This actually makes a lot of sense with things like the order detail grid. You only want to find different parent records. Normally avoid this by not having any main-table indexed fields in the grid, which is what the samples did. If you added an index to OrderDtl.Qty, things get strange. Now that can be controlled.

-John

John Tuohy
9-Jun-2010, 07:33 PM
I think this relates to my previous post about the lack of a search popup object for searching Grids below the Prompt list level.

...

The search objects of the prompt list need moved down the heirarch to the cCjGrid class and above.

I guess the point is the autofind/search is acting on the displayed grid not the record buffer thus searching the displayed grid representing the underlying datasource is the issue.

Perhaps autofind could be tapped into to trigger the search and or search popup.

This is the last major enhancement i would like to see before the Beta is released.

Moving the popup search feature up the class hierarchy is possible, but I am concerned about expected use and and even more concerned about expected misuse. Do you expect a search feature like this to work side-by-side with a data-entry grid or is it one or the other? The prompt lists don't support editing and in that kind of environment the popup search feature make good sense. If data entry gets mixed into it, it gets pretty fuzzy. Trying to tie any of this into autofind, which is designed for data-entry seems like a step in the wrong direction.

Do you need this mostly for regular or non-data aware girds?

Are you willing to use specialized sub-classes to do what you want?

-John

Tom Murphy
9-Jun-2010, 08:21 PM
Hi John

I would have expected it to work like the old dbGrid, where entering an existing 'key' value and then pressing tab or enter in our case would find the existing record. A number of our maintenance type views use dbGrids, we believe a user should be able to go into the view, the focus will be on the 'key' value column and enter an existing 'key' value press enter and find that record.

In the case of the up and down arrows, I agree the behaviour in the old dbGrid is somewhat wierd, you enter an existing 'key' value and then press up, you don't go to that record but the one above it (or below if you pressed down), but at least you are near to where want to be.

The other issue is on new lines, enter an existing 'key' value and press enter, it doesn't find the existing record and there is no error (unless I create my own validation routine). You carry on entering all the data for the new record and when it saves it gives you duplicate record not allowed error - a bit late in my opinion.

You mention the peRequestFindMode property whose default is to act like the old grid, can we have a property to allow the Auto Find to behave like the old dbGrid, pbMainTableAutoFind?

John Tuohy
9-Jun-2010, 09:51 PM
So you really want the tab key to jump to target record and then move to the next column? It sounds like you use the Enter like the tab key, so it would do the same. Is that what you want?

-John

Tom Murphy
9-Jun-2010, 09:55 PM
Hi John

Yes thats what we are after, and yes we have pbEnterAsTabKey set to true.

Cheers

Russell McDougall
10-Jun-2010, 04:30 PM
eI went back and asked the users who do high speed data entry what they want.

1. None ever used or wanted to use the tab key for any reason including advancing to the next cell. Always use the enter key to complete data entry in a form or cell and advance to the next row. In our software, numbers and dates form a large bulk of the entry and their fingers are near the enter key.

2. I sense a feeling that prior to this new grid effort DAW believed the tab key was the primary key to move between cells and this has created much of the earlier debate about the new grid. This arises from thinking of grids as spreadsheets rather than a series of horizontal dbforms that logically group together to complete the entry of a new record. The users were quite clear they view grids as the latter. This is why i really like the new column object code style.

3. They are perfectly happy with the new style grid as set out in the order entry example. The prompt list works well to latch find and latch onto a new code.

4. When doing entry into a customer type grid they want:
If presently on the first cell of a customer type grid say customer 2 and want to key and latch onto 10 they want a search object popup like the prompt list to key into which would popup on key down. They key 10 expect it to find 10 latch on and move to cell 2. They don't want the old grid style of overtyping 10 into customer no 2 as it is non intuitive. If 10 does not exist they want to be positioning into the first cell of a blank line to enter a new customer or, if coded, be presented with an info box telling them 10 does not exist would they like to create it. Alternatively some want to goto 10 or higher similar to the searching in the prompt list search box.

5. I still argue to move the search objects down from the prompt list to the bottom cCjGrid because if subclassed it makes sense that we could tap into this at the lower level without conflicting with the code in the Promptlist.

6. Users want no difference between searching and finding in non db grids and db grids. Consistency was their prime request. As an example we have an accounting system which scans folder names dynamically displays them in a cCjGrid and needs to be search alphabetically. Again with a search popup on key down. This was possible in the old list class albeit with incremental search rather than a popup. This functionality is last in the standard new cCjGrid. In other words one of the uses for cCjGrids is as non data aware prompt lists. Perhaps this is a missing class in the new grid heirarchy.

In summary i believ the new grids would be enhanced by.
1. A non dataaware prompt list.
2. The ability to code the utilization of a search popup object in a grid column as a simple user interface to requestSearch. This makes all searching consistent with searching in a prompt list.

John Tuohy
10-Jun-2010, 07:00 PM
Russell,

Thanks for the detailed reply. I'll have to think this over.

It would actually be pretty easy to create a non-data aware prompt list. Someone could probably do that in less than a day. Putting it in the product is another issue. The prompt list is actually pretty simple and there is not all that much code there. It would be a little easier if some of the search interfaces were moved into cCJGrid but it would still be pretty easy to do.

Would you consider it useful to have the request-search capability built into the grid class without trying to make it automatically popup when you type a character? That part kind of worries me because that may not mix well with a data entry grid. The prompt lists do this at a grid level and not at the column level. Making this work for one column and not for another, while possible, would require some careful thought. Making this work conditionally within a single column gets even more problematic. If the limitations of this are not specified up front it will get misused and we will complaints (actually if we specify the limitations it will still get misused but we get fewer complaints). However, if this is something that is invoked via some kind of key or button, it may be less of an issue.

-John

John Tuohy
10-Jun-2010, 07:53 PM
Hi John

I would have expected it to work like the old dbGrid, where entering an existing 'key' value and then pressing tab or enter in our case would find the existing record. A number of our maintenance type views use dbGrids, we believe a user should be able to go into the view, the focus will be on the 'key' value column and enter an existing 'key' value press enter and find that record.

In the case of the up and down arrows, I agree the behaviour in the old dbGrid is somewhat wierd, you enter an existing 'key' value and then press up, you don't go to that record but the one above it (or below if you pressed down), but at least you are near to where want to be.

The other issue is on new lines, enter an existing 'key' value and press enter, it doesn't find the existing record and there is no error (unless I create my own validation routine). You carry on entering all the data for the new record and when it saves it gives you duplicate record not allowed error - a bit late in my opinion.

You mention the peRequestFindMode property whose default is to act like the old grid, can we have a property to allow the Auto Find to behave like the old dbGrid, pbMainTableAutoFind?
It would be possible to provide a property for this but let's make sure this is the best way to solve your problem.

You mention the adding a new record where you enter an existing key but you are not warned until you save it. I can see how that's an issue but is autofind the way to solve this. You open a new row, you type in an existing value, press tab (or enter) and suddenly you grid has refreshed and you are no longer in edit mode. When adding new records in a grid and doing an autofind on the main record, it seems like you want a "auto-not-found" validation and not an autofind.

I assume the other reason you want it is for searching for some item and refreshing the gird around it. As we've discussed that has some odd side-effects. Maybe there is a better way to do this.

-John

Russell McDougall
10-Jun-2010, 11:16 PM
Yes i believe it should work exactly like you say.

I made my own subclass by grabbing the DB Prompt list and cutting out all the data stuff. Rough but it works. I did that in the absence of a new class to replace the list class.

John - just a side comment - the more that I code the new grids the more I like them. The clincher was the understanding given at the beginning of the second webinar when you morphed one type into another. Suddenly everything clicked.

Once the alpha stage is over I believe the angst will have been worth it.

Clive Richmond
16-Jun-2010, 02:41 AM
Hi Russell,


4. When doing entry into a customer type grid they want:
If presently on the first cell of a customer type grid say customer 2 and want to key and latch onto 10 they want a search object popup like the prompt list to key into which would popup on key down. They key 10 expect it to find 10 latch on and move to cell 2. They don't want the old grid style of overtyping 10 into customer no 2 as it is non intuitive. If 10 does not exist they want to be positioning into the first cell of a blank line to enter a new customer or, if coded, be presented with an info box telling them 10 does not exist would they like to create it. Alternatively some want to goto 10 or higher similar to the searching in the prompt list search box.

This approach does seem to go against the goals and design principles of CUA. The quote below from IBM's SAA CUA Guide to User Interface Design sums up the differences.


Program-driven interaction is like riding a train: a user must go where the program goes, according to its schedule. A designer should aim for user-driven interaction, which is like driving a car: a user goes where the user wants, according to the user's schedule. A product should allow a user alternative courses of action and should not limit a user's capabilities by imposing a designer's or programmer's preconceived notions of the 'correct' sequence for accomplishing a task.As a general rule we tend avoid popping up modal containers and, if we can, achieve the same thing in a non-modal way. However judicious usage of modal containers does have a role to play in any application.

Personally I'd like to see the lookup's search function not as a pop-up but integrated into the container as a form. As soon as you start typing it becomes visible, takes the focus and starts finding the nearest match in the list. As soon as you either press enter or move away the form disappears. This is similar to how Firefox's find works but without having to press Ctrl+F first. It would also be a great replacement for the Studio's find and get away from the modal-container it currently uses.

Russell McDougall
16-Jun-2010, 06:41 AM
Clive - Thanks

That is what i was saying just not clearly.

The popup i was trying to explain is the search form contained in the top of the DbCjgridPromptListClass that appears on a key down event.

I did not mean to imply a prompt list should popup.

I wanted the search form moved down to the cjgrid class or perhaps a column class as a user interface to the column searching that exists at the lower level albeit with no user interface.

Then we could apply column searching to all higher levels.

I ahve down that with a subclass and find it very good.

Tom Murphy
16-Jun-2010, 08:42 AM
Hi John

Sorry I missed this reply, let us have a think about your comments and we'll get back to you with our thoughts how we think it could work.

Clive Richmond
17-Jun-2010, 12:04 AM
The user types in a target and then they press some key. What key do they press? Enter? Tab? Up arrow? down arrow? What happens after the auto-find? Does it do an autofind and then do whatever the key does (like move to the next column or row)? That's what the old grids did and it just didn't seem to make much sense. You always ended up in the wrong column (e.g., Tab) or off your target by one value (e.g., up or down arrow). If you had changes in the row they were lost. This all happens because Autofind was not really intended to be used on main files in grids. It becomes an uncontrolled find.

It is navigation within the current row via the keyboard or mouse where autofind is important. The potential for lost changes does exist but I would suggest this is consistent with how autofind works with dbforms and the main table i.e. no data loss confirmation and it simple loads the new record. The refresh may also take you to a totally different area of the grid. This outcome is more desirable then entering X number columns plus related data in a panel to the right only to get a duplicate record not allowed error when you attempt to save. From our own experience database columns with an autofind always appear at the start of the gird i.e. similar to how data-entry would be structured using dbforms. In addition such database-columns are usually protected by key_field_state.


You type your target and press find, you've got your search and you are still in the right column. But if you do it that way, you don't need autofind at all. Either way it's the exact same number of keypresses.

Agreed assuming you wished to stay in the same column :). However in the current grid with forward navigation via the keyboard or mouse, not only finds and displays the record, but it also places you in the next available column (or clicked column) and ready for data entry. That's one less keystroke.

The old grids finding maybe didn't make much sense viz moving up / down and ending up on the wrong row etc and perhaps this behaviour is something we've just got used to. So we are certainly open to new ideas here.

For example if a main table autofind was only effective when navigation remained in the current row then the existing behaviour would I think be acceptable. The current behaviour, when navigating to a different row, as I understand it is this:


Attempt to change the focus and let the server structure do its stuff i.e. validation, confirmation, save.



Depending on the business rules and if it is an edit or a new entry etc a variety of outcomes exist including:

validation fails
confirmation message displays allowing the user to direct what happens next
save fails, with duplicate record not allowed error

Tom Murphy
6-Jul-2010, 01:32 AM
I notice this change didn't make it into the beta.

John Tuohy
6-Jul-2010, 11:36 AM
Still deciding what to do with this. I don't think we want to extend the current autofind capability for grids quite yet (too close to the end and too big of a change). So it comes down to changing the behavior to make it work the way it used to, using the new behavior or providing a property to offer both. I'm hesitant to make it optional because it may make it more difficult to provide a future solution that could incorporate some of the above suggestions. We might just restore the old behavior. It appears that most people accept it and that you've learned to use some of the odd behaviors to your advantage.

-John

John Tuohy
7-Jul-2010, 02:44 PM
Tom, Russell and all,

Please check out http://support.dataaccess.com/Forums/showthread.php?p=210938#post210938.

-John