Finds

Classic Servoy
1

I’m not sure whether this is a bug, but I can testify that it’s an issue. Currently, it’s the number one issue in the solution I’m developing. I’ve actually disabled the find in the production database (which thankfully doesn’t have much activity yet) until these issues are addressed.

I have a number of threads going on this topic already. I appreciate all the help I’ve gotten thus far on this (and other topics). I’m just bringing my whole ‘find’ issue together here. Don’t take my urgency as an indictment of Servoy, or the outstanding support I’ve gotten. Also, don’t assume anything below is a bug. Remember there’s a relative newbie at the keyboard. :wink:

All that being said, here we go:

  1. I understand that method triggers aren’t supposed to go off in find. They do, though, in my solution. See thread Status(CurrentMode) - #13 by Cain - Classic Servoy - Servoy Community. onEditRecordStart, onNewRecordCmd, etc. trigger. Thing is, these methods aren’t meant to work in Find mode.

  2. I also need to know how to capture that the user is in find mode. This is especially important if methods keep kicking off, but also so that I can indicate to the user that they’re not in the browse mode.

  3. At this point, part of the problem may be that I can’t seem to follow the chain of events when I do a find myself, in the UI. See thread Find Issues? - Classic Servoy - Servoy Community. Even as a user, all Methods aside, I have trouble knowing whether I’m in find or not.

  4. In a method, if I use the find() command on the current form, the method seems to stop, even though there are following commands to set a value and search(). Is this expected behavior? Should I just go to a separate form for any scripted searches?

  5. Does anyone have a working example of a find routine? I need two things from a find routine: clear indicators for the user, and a clear indicator for methods. I’m sure someone has been through this before, and there must be a graceful solution, but none of the examples I have use anything but DEFAULT. The DEFAULT find would work if it were more obvious (and consistently shown) that the user is in Find and if Methods either could be disabled or could accurately branch when in Find mode.[/url]

2

<1>

This is a bug or something wat youre place that is going wrong. No script should be able te execute.

<2>
Because of <1> there is no need for this. Because you should never be in find mode when a method is triggered. Except if you do the search yourself in a script and then yes you know it youreself…

<3>
see also <1> and <2> Besides that i have fixed the status text when in find mode. The status text is enhanced now so that it will always show the right thing.
Also deleting a record in find mode is fixed for release 2.2

<4>
stops? I have never seen this. This has to be something of youre solution/system.
for example this should work fine:

controller.find();
dataprovider = ‘Cain’;
controller.search();

Please if you see this behaviour always always make a very small and simple solution and do only this. (that’s what i do all the time when i try to reproduce behaviour)

<5>
Clear indicators for a user is fixed now (when the pess new or delete record in finde mode)
An indicator for methods is not needed because you shouldn’t have access to it anyway.

3

To summarize:

  1. event triggers in find: possibly my own personal raincloud. :cry: Sending solution to Johann for confirmation.
  2. currentmode scripting function: absolutely no methods in find? Please confirm.
  3. Status text and request deletion: fixed in 2.2
  4. find command stops method: PEBKAC error. :oops: Not an issue.
  5. Alternate find routines: Overall confusion and cry for help.

  1. I’m sending a small, simple solution to you back channel (since I can’t attach). It has simple dialog methods for onSave and onEdit. I couldn’t reproduce the any of the other triggers, so I’ve probably misinterpretted these two, which happen, f’rinstance, when you create a new record.
    This may well be ‘only at my place’, but it’s at my client’s place, too, so I need to figure out how to make it stop. Besides, from what you’re telling me, this not only shouldn’t happen, I shouldn’t be able to somehow make it happen, either, even by mistake.

  2. No methods at all are supposed to work in Find? Not even buttons? So if I had users doing a find in a dialog form, they couldn’t use a ‘Done’ button? Aside from the triggering methods in (1), this seems to be the behavior I’m seeing. Could you confirm this for me, though?
    Assuming I’m understanding you… For example: I have a custom controller with an editable (global) field for the current record number. This allows the user to go to a record by number. How can I display/update this number in the find mode?
    I can’t get my mind around this. Can you help?

  3. Thanks, Johann!

  4. :oops: I created a simpler solution, and found that I’d misinterpretted what I was seeing. This is not at all an issue.

  5. ‘Consistent’ indicators will be fixed, but ‘more obvious’ won’t. Users will frequently miss the 12 point message in the lower left corner, and enter about 8 records or so in the find mode before they realize it. For this reason, I generally at least change the background color.
    Considering that no methods will trigger, there are other ‘maintenance’ issues to take care of, such as the current record global mentioned above. For any of that to work, I need a clear trigger coming OUT of find, and/or a function to return the current mode of the user.

Can any other developers weigh in on this? Given some evidence, I’m prepared to concede that I’m nuts, here, but I currently can’t come to a satisfactory conclusion one way or the other.

I know that in FMP, it’s almost religion never to leave just the default find behavior, and in FMP there’s much more control over the find, with currentmode, pause/resume, etc.

Is the find functionality unmodifiable? (i.e. out of our hands once the find() commande executes?) I don’t expect Servoy to have a robust, be-all and end-all find routine, any more than I expect ready-made layouts or a robust default controller. However, I’m not seeing how to augment the find routine.

Are others finding the DEFAULT sufficient? Do users really ‘get’ that?

Is there some other, graceful find routine that works, that someone could share even the bare bones of?

4
  1. Johan confirms that some event triggers, when tied to global methods, were triggering in Find, and that this will be fixed.

I’d still like a status(currentmode) equivalent, but as I said before…

Can any other developers weigh in on this? Given some evidence, I’m prepared to concede that I’m nuts, here, but I currently can’t come to a satisfactory conclusion one way or the other.

I know that in FMP, it’s almost religion never to leave just the default find behavior, and in FMP there’s much more control over the find, with currentmode, pause/resume, etc.

Is the find functionality unmodifiable? (i.e. out of our hands once the find() commande executes?) I don’t expect Servoy to have a robust, be-all and end-all find routine, any more than I expect ready-made layouts or a robust default controller. However, I’m not seeing how to augment the find routine.

Are others finding the DEFAULT sufficient? Do users really ‘get’ that?

Is there some other, graceful find routine that works, that someone could share even the bare bones of?

5

status(currentMode) isn’t needed at this time because of script not running in find mode.

We do have one thing in the planning an that is a method that can be exacuted on the event onSearch. So triggered when the users pressed F3 or enter in a field.

You already have the onFind where you can preset somethings for the find mode.

6

I’m with Cain in discomfort with Servoy’s style of implementing Searches. I haven’t really weighed in on this subject much because I’ve implemented and augmented Mattman’s Find-In-A-Custom-Controller routine and that’s fine for now. Matt’s routine is excellent for a quick find on a single field – show me all the Mary’s in the system or Invoice 123.

However, when I started to put together a routine for more complex finds – all companies starting with the letter C in a postal code range of 123 to 234 which haven’t been contacted in the last 6 months – in other words involving multiple fields and needing popups and script assists to make it fast and easy, I ran into the “no scripts” roadblock and backed right away.

I’ve yet to see any examples of an end-user friendly interface for building complex searches. From my FMP experience having buttons really help. And definitely, definitely, definitely a “knock em on the head” signal that they’re in Find mode is absolutely essential. A single word in one corner of the screen is fine for a developer but not for average users.

What do other developers have to say on this subject – or you just hanging back like me because it’s too big a challenge right now and there’s so much else to turn one’s attention to?

Comments anyone?

7

What kind of visual clue would you have more to say that he is in find mode?

Don’t forget… The person behind the screens did trigger the find mode themselfs!! So they are knowing that they are in find even without seeing anything.

8

How about changing the background color?

I see what you’re saying, Johan, and for myself as a user, I would agree. Our end users aren’t as well-behaved, though. :wink:Users don’t go through the find process in lockstep, nor do they always realize the implications or side effects of being in the find mode.

Consider the user that’s interrupted by a ringing phone, or a user that comes to the screen that’s already in use by a co-worker. And even more likely, imagine the user who just plain forgets; click ctrl+F, and then change your mind, and try to hit a button or whatnot to go to another screen. First reaction: “it’s broke”.

There’s no true cure for untrained or scatterbrained users. Our systems would be much better if those darned users would leave them alone. :) In this case, though, we just need a way, like Morley said, to “knock em in the head” and let them know that they are definitely in a different functional mode, and not only should they be behaving differently, but they should expect the solution to behave differently, too.

9

In FMP I was able to build a special “Search” form which provided both fields and button assists and bore no relationship to regular data entry. The user gained access to this form by a button which put FMP into Find mode. Typically this search screen would include buttons which would set common search settings which the end user could then fine tune. Two buttons would provide for exit. A Cancel button to get out of Find mode and return to the previous screen, nothing changed, and a Search button which initiated the actual searching returning the user to a record view layout if only one record was found or to a table view layout with two or more.

In this way there’s no confusion about modes, of attempting to create new record data while in find mode, etc. I’m definitely not comfortable with letting users perform searches on the same forms they do data entry. A source of confusion and frustration for inattentive users who are wary of computers.

Am I correct that such a style is not currently available within Servoy?

10

we can’t just set a background color. Then other developers would go mad :)

You could try to visuallize it youreself better if you really need it when overriding the onFindCmd but to be completely save you also should have then a onSearchCmd to revert it back..
But his features will come after 2.2

11

Cain:
Consider the user that’s interrupted by a ringing phone, or a user that comes to the screen that’s already in use by a co-worker. And even more likely, imagine the user who just plain forgets; click ctrl+F, and then change your mind, and try to hit a button or whatnot to go to another screen. First reaction: “it’s broke”.

There’s no true cure for untrained or scatterbrained users.

Well said.

12

what could be a posibillity was setting it in the title or something like that

Solution name - Form name - Servoy Client (Find mode)

13

jcompagner:
what could be a posibillity was setting it in the title or something like that

Solution name - Form name - Servoy Client (Find mode)

With respect, that’s slapping a label on something but not actually changing it at all. You’re still trying to get people to think of “modes”. And for some people that’s tough, a really tough concept.

When a user goes into search mode the whole environment needs to radically change. The look, the feel, the aids, everything. Pretty much as the example I provided earlier. Only then does it become obvious and self evident they’re in a searching situation. A glance at the screen (NOT left brain reading but right brain looking) is all that’s required.

I’m really surprised we’re having this discussion. This theme has come up again and again and again in the FMP world over the past several years. End users really do get distracted, interrupted, insufficiently trained or are just plain tired and start behaving in Find mode in ways that are only appropriate in Browse mode. And occasionally vice versa. Users become extremely frustrated if they enter 100 records of new data only to discover they’ve been in Find mode all along.

In the FMP world, as I’m sure Bob Cusick will confirm, it’s extremely common to put up specific layouts for processing searches. In my own FMP version I provide buttons next to fields which conveniently provide popups of the index of a field for fast and appropriate input of search possibilities. That and other buttons and popups that fill in common searches, which then can be fine tuned.

Most important of all, which to the best of my current knowledge Servoy does not provide at all, is a painless and simple way of exiting out of Find mode without searching for anything. The phone rings and you now need to change directions and start entering data. If there’s a way of doing that in Servoy I don’t currently know it. Equally important – something on the screen like a button that will do that, not something they need training on, some pull down menu or key stroke they need to remember to use.

This is very important user interface stuff. I’m startled there hasn’t been more discussion along these lines in Servoy Forum – or I’ve missed it.

Cain’s right. We need to be able to provide an unambiguous Search environment that is much more radically different than just disabling all buttons and putting a label somewhere on the screen or changing the background colour. We need to be able to serve the user who genuinely isn’t comfortable with computers, the user who tends to get confused, inconfident and doesn’t think in terms of abstractions such as “modes”.

Comments from others?

14

Hi Morley,

Here’s my suggestion - if you don’t like the fields “blanking out” - do what I do - show a “find” dialog (hooked to the “onFindCmd” event of the form). Done. You can do WHATEVER you want. Change the color of the background, change the field colors, whatever.

You could also duplicate your entry form - and make that the search form in the dialog - and make all the fields green if you want.

You have to remember a KEY POINT in FileMaker versus Servoy - Servoy is NOT FileMaker! :D

FileMaker controls the database - so this “find by example” thingie (i.e. find mode) works. Servoy uses SQL (only!).

15

i agree with bob, if you want something different make special find forms/dialogs..

There are ways to get of of find just fine:

Enter (in textfield) or F3: Search
CTRL-J to browseAll/cancel search.

16

jcompagner:
i agree with bob, if you want something different make special find forms/dialogs.

Can I attach a method to the actual Search proceedure? When the user clicks the Enter key, I’d like to evaluate whether they found something or not, branch to an appropriate layout if the search was successful, branch to another routine if nothing found. Is this possible?

Merry Christmas, all.

17

please READ this thread!!
This is on the planning right after 2.2

18

jcompagner:
please READ this thread!!
This is on the planning right after 2.2

Excellent. Thanks, missed the original reference.