Good find approach

[J__]

hello,

I have a main layout, which contains a button that calls a script which does a find. in that script , among other things, I basically switch to a layout which contains the records fields in it and have a Enter Find Mode [Pause] and let my user enter some criteria, they then can hit the enter key and Perform Find[] is called.

Based on that If I have > 1 record I switch to a list view layout and let them pick the one they want

if the recordCount Found = 0, i ask if they want to find again and give them another go

if the recordCount Found = 1 then i switch to the 1 record view layout and let them work with the layout there.

My problem is that i have buttons in the find view - basically a nav bar, which I display in most screens. my user can press one of those - while they are in find mode!!! and then find never finishes finding. I do call Enter Browse mode[] and this works sometimes, but not all the time.

I was wondering whether anyone has approaches which work really well or any tips on how to handle this - or maybe some "Cancelfind" function which makes it all ok when i call it.

thanks for your help in advance,

sincerely,

J__

[Ender]

In the button definition dialog, select Halt Script in the Current Script menu. This will kill any currently running scripts and allow subsequent nav scripts to work correctly.

[J__]

I'll check that out - thanks. I hadn't noticed that option in the button dialog would make things behave differently like that.

does this mean i should ditch any enter browse [] stuff and halt scripts in there?

thanks,

J__

[J__]

ah, what you meant was the other buttons right? For example, I have a [go to main] button a [Find] button and a [Print] button.

I should set this for all of them. So when i click them it breaks out.

I couldn't find anything on this setting in the help what does this mean for other scripts under those buttons? Are there any gotchas or caveats to using this?

thanks for your help,

sincerely,

J__

[Ted S]

Another approach would be to test for the current mode on your EXISTING scripts and only proceed if the mode = 0 (for Browse).

Take a look at the Get(WindowMode) function.

[Ender]

J, the trickiness you might run into is when you have processes that you don't want interrupted by Halt Scripts on buttons. Say you have a data entry screen with a Process button that checks to make sure all fields are filled out correctly. In this case do you still want users to be able to leave the screen without processing? Probably not. So how do you enforce the Process script? You could remove the navigation buttons, or have the Process script running while on the data entry screen, then use Resume Script as the button option on navigation buttons, and a Resume Script as the function for the Process button. In this case a Halt Script as the button option would defeat the process.

Another option that is even less understood is the Exit Script button option. This exits only the current sub-script, but allows parent scripts to continue running.

[J__]

Ender,

thanks for the response. Right i hear you about the process button and bypassing it.

how could you remove the navigation buttons without doing a new layout? I know there's a trick to this, do you know it? something with case and containers maybe/

thanks,

J__

[Ender]

You're probably thinking of the portal visibility trick (you can search for that if you need details,) but I usually design a data entry layout, a view layout (that looks similar but with non-editable fields,) and a find layout. My find layout is a more general layout with just the fields I want to allow finds on (it is similar to the list view, and with results in a list view). The find layout still has the main nav buttons on the top, and if the user wants to abort the find, that's fine (just use the Halt Script option on the buttons.)

[J__]

halt option worked great thanks!

I design like you. But a user wants one screen to do it all!!

they said "it will be easy, just remove the other screens"

.. not as easy as it sounds.. validation is a bear.. we'll see what else.

thanks again,

J__