July 29, 200916 yr Is there a technique for determining the foremost window? If there's a suitable Get function, I'm not seeing it. With kind regards,
July 29, 200916 yr FileMaker evaluates all functions and performs all actions in the context of whatever window is frontmost when it started evaluating/performing. Therefore simply get(windowname) will do what you need. Hope that helps. James
July 29, 200916 yr Author Neither suggestions will work in this situation. Here's the context. The end user clicks on a button, causing a new, quite small window to open up, overlaid on the background. The background is important, because it gives the user context for the choices in the overlay. The user must interact with that overlay and use a "Done" button to close it. However, if they click randomly in the background layout it will now cover the overlay, obscuring the "Done" button. Ideally I'm looking for a Get ( Foremost Window ) function, or an equivalent, which can be part of a script trigger attached to the background layout. If that window is clicked, then the overlay window pops back on top. That's the functionality I'd like to deliver to the user but have yet to figure out how to deliver it. Any ideas? Much appreciated.
July 29, 200916 yr Would this script not do it: If [ get(windowname) != "overlay" ] select window "overlay" end if I don't have a not-equal-to sign on my phone :-) Hope that helps James
July 29, 200916 yr Author Would this script not do it: If [ get(windowname) != "overlay" ] select window "overlay" end if I don't have a not-equal-to sign on my phone :-) That's part way there. But how to trigger it when all the user has done is to click on a neutral area of the background layer? With kind regards,
July 29, 200916 yr If I understand you correctly, what you need is not a way to reference the foremost window -- that part's easy -- but a way to trigger a script on window entry. I have been wanting something similar. I don't think one exists?
July 29, 200916 yr If you put the user inside a paused loop, it will prevent them from clicking on the background window.
July 29, 200916 yr Quite so. Allow user abort off Loop pause End loop will keep your user in a loop that they can't get out of, and they won't be able to click the background window. All your buttons on the active (front) window should be defined to EXIT current script when called. Bear in mind that if the user needs to be kept in that window after pressing a button, you will need to put them back in to the loop again. The AUA off is important because it prevents the user from closing the window. James
July 29, 200916 yr That's part way there. But how to trigger it when all the user has done is to click on a neutral area of the background layer? With kind regards, You'd have to make the background window in to a button. And they'd have to click twice (once to activate the background window, once for the button). If you're trying to do what I think you're trying to do, then the AUA+loop answer above is the way to go. J
July 30, 200916 yr Another way is to make your buttons RESUME the current script and build the loop something like this: Loop Pause/Resume Script Exit Loop If[1] End Loop Another way is to make your buttons Resume but also call a one-line utility script that looks like this: Exit Script[Result: Get( ScriptParameter )] Your buttons can pass in parameters such as "cancel," "OK," or a field value. Your loop might then go like this: Loop Pause/Resume Script Set Variable[$result; Get( ScriptResult )] Exit Loop If[not IsEmpty( $result )] End Loop I use variations of this method quite a bit.
Create an account or sign in to comment