Buttons

[jcarson]

Does anyone know how to turn a button off in find mode? I want to be able to click on a portal field and go to a related record, but I'd like to also be able to search on the portal field.

Thanks.

[MoonShadow]

If [ not Get(WindowMode)

... add portion of script to do whatever you want to do in Browse

Else

... do what you want while in Find or Preview

0 = Browse

1 = Find

2 = Preview

Or you could write If [ Get(WindowMode) <> 1

... do Browse or Preview stuff

Else

... do Find stuff

Or any combination thereof.

[jcarson]

I tried that. I made a script that is

If[ not Get(WindowMode)

Go to Related Record

Else

Perform Find/Replace

End If

So now it goes to the related record in browse mode, and in Find Mode it does nothing, just stays in find mode like I told it to, but I still cannot enter any data into the portal field I'm using as the button in Find Mode.

[MoonShadow]

Perform Find/Replace

Wrong script-step. Try a little further down in 'Found Sets' and look for Perform Find. Perform Find/Replace doesn't perform finds - it finds and replaces text in Browse mode so you remain in Find Mode and your Find never executes.

[jcarson]

Ok, made that change, but it still doesn't let me enter any information into the field. Anytime I get the Mouse on that field it turns into a little hand, whether I'm in browse mode or find mode even after I've clicked on it to run the script.

[MoonShadow]

The 'little hand' indicates that there is a script attached. It may be attached to the field or placed as a transparent rectangle over the entire portal row.

Right-click field and be sure Field Behavior checkbox Allow Entry in Find Mode.

If you still can't identify the script, drag around the entire portal first row. Handles will appear and may make a transparent rectangle obvious. Transparent rectangles are difficult to grab because you must grab them on their LINE and not in the middle. Somewhere, you have another script attached.

[MoonShadow]

You're attaching the script to the field itself! You mentioned that fact but I thought you had a button in the portal. So, a quick regroup:

Have a BUTTON called Find on the main layout. It would be something like:

Enter Find Mode [ Pause ]

Perform Find [ ]

Then turn off entry into portal field in Browse mode but leave entry in Find Mode (in Field Behavior). Attach another script to your portal field which is:

If [ not Get(WindowMode ]

Go To Related Record [ ]

End If

When User clicks the field and they are in Find, it will allow them to enter the field to type their criteria. The user will still need to hit [Enter] to execute the Find (resume). Because otherwise (as you originally had your second script) the script attached to the field will fire (Perform Find) before the User can type anything into the field. Catch 22 here ... You can't have the script Perform Find when User clicks the field.

[BobWeaver]

I think this may be what needs to be done in the script for the button attached to the portal field.

If [Get(WindowMode)=1

  # Find Mode - enter the clicked field

  Go to Field [MyPortalField, Select]

Else If [Get(WindowMode)=0

  # Browse Mode - Go to Related Record

  Go to Related Record [yada yada]

Else

  # Preview mode - Do nothing

End If

[jcarson]

I must've changed the script around a million times. Never could I click on the field in find mode. I did however find that I could tab into the field in find mode. So I can perform the searches I was hoping to.

Thanks.

[SlimJim]

A simple-minded possibility: Make a copy of the layout and remove all the button definitions that you do not wish to be active in find mode. Then put a Find button in the main layout which changes to the copy layout and puts you into Find mode. Enter the find criteria and have a Continue button which does the find and switches back to the main layout.

[BobWeaver]

The go to field script step that I had in my example above will force entry into the field even when the field has a button attached.

[MoonShadow]

Or just do what I usually do ... provide dedicated find layouts. Technique is simpler to implement and easier to police. Good scripting can handle it however, as Bob has shown.

[BobWeaver]

Right, I generally use a separate layout for finds too.

[MoonShadow]

Ah. Fool the User huh, SlimJim? Let 'em think they're still on same layout. I've used that a few times but had forgotten how much I liked the concept. I enjoy trickery and illusion.

I've reverted to making my find layouts VERY obvious (and I eliminated the problem of changing Browse layout and having to make same visual changes to Find layout). Wanted it very obvious because User's were always confused on which mode they were in. My Find layouts are always yellow. Same bright yellow as these emoticons.

They don't perform a whole heck-of-a-lot of finds anymore.

[SlimJim]

I like to think of it has helping the User. If they are used to a name field being in a certain position on a layout then they will naturally put the name in the right place when performing a find, but this only applies to simple finding. Anything which requires multiple find requests, date ranges, etc is best done in a special layout and the user protected from the mechanics by scripting the find.

[stanley]

I usually provide two different find buttons in my solutions - a "quick find" which only shows the commonly used fields, often with drop-downs, in a clearly different layout, and a "find", in which all the elements are in the same position as in other modes, but with a clear indicator (color and text) that the user is in Find mode. I do that not to "fool" the user, but so that they can work more intuitively - the user knows where, for example, the Fax Number field is in a complicated layout, because they look at the Browse layout all the time. They shouldn't have to look for it when they are doing a find.

-Stanley