Page 1 of 1
Modal window techniques
Posted: 17 Nov 2022 12:46
by ColeValleyGirl
This discussion is prompted by the Thu 17th Nov 2022 12:18 posting in
Change any Fact plugin (21179).
Why not just use the FH API as documented?
fhPromptUserForRecordSel(strTag [,iMaxSel[, hParentWnd]])
and
hParentWndRequires version 7 or later. Optional parent window handle ('light userdata'). If you are calling the function from a dialog box, such as an IUP dialog box, you must pass in the window handle of the dialog box - see second example below.
It does of course mean you have to code slightly differently for FH6 and FH7.
Re: Modal window techniques
Posted: 17 Nov 2022 13:05
by Mark1834
Mike will comment on the specific of this plugin, but my general approach for FH6 is that if this adds a lot of complexity or extra code, I don't do it for new plugins. However, if backwards-compatibility is easy to achieve, I don't go out of my way to break FH6. So for this type of example, I would probably adopt the FH6 version of either hiding or deactivating the parent window while the secondary one is active. It's only a couple of lines extra over an FH7-only version, and simpler than mixing FH6 and FH7 ways of doing things.
Re: Modal window techniques
Posted: 17 Nov 2022 13:07
by tatewise
Helen, I must be doing something wrong because for me it did not work entirely successfully in FH V7.
Code: Select all
strType = "INDI"
iup.SetAttribute(dialogMain, "NATIVEPARENT", fhGetContextInfo("CI_PARENT_HWND"))
local arrRec = fhPromptUserForRecordSel(strType,-1,dialogMain.HWND)
While the Record Select dialogue was displayed the original plugin window IUP dialogue controls were inhibited.
However, there was no indication to the user that the controls were inhibited.
i.e. They are not greyed out as when
dialogMain.Active="No" is used.
BUT the Close X button in the top right corner was NOT inhibited, so the plugin window could be closed.
That leads to the same frozen running plugin as we are trying to prevent.
So I will be sticking with the far more transparent (sic) FH V6 compatible
dialogMain.Active="No" method, which I would have to use in FH V7 anyway to grey out the controls.
Re: Modal window techniques
Posted: 17 Nov 2022 13:22
by ColeValleyGirl
As I commented in another thread
fh.getParam question (19055) when this first came up, I have resorted in the past to hiding the X button and including a specific Save button/menu item plus a Cancel one (which has the advantage of being explicit about what will happen on exit (but does disable Minimise and Maximise).
However, i'm seeing the C in the top right disabled when the FH selection dialog displayed, along with the rest of the plugin interface (which is what I'd expect as the selection dialog is modal). (An example is the Civil Registration Index DEA).
Re: Modal window techniques
Posted: 17 Nov 2022 16:32
by tatewise
I prefer to keep the plugin dialogue windows, like most Windows windows, and retain the top right controls.
I presume in your last paragraph that C should be X
My guess is that FH is in control of the X you are talking about there when it displays a Record Select dialogue.
I can't see anything in the Record Civil Registration Data (UK) DEA script that performs any prompts or uses IUP HWND.
It certainly does not use the FH API fhPromptUserForRecordSel(...)
So that seems to be a rather different scenario.
Like Mark, IMO it is just as easy to use the Active attribute with the benefits of FH V6 compatibility and greyed-out controls.
Re: Modal window techniques
Posted: 17 Nov 2022 17:09
by ColeValleyGirl
Yes, that C should be an X but it's the X in the plugin window,
not the FH Record Select dialog.
For clarity:
- Screenshot 2022-11-17 170145.jpg (126.11 KiB) Viewed 1247 times
The PLugin window is totally unsuable.
tatewise wrote: ↑17 Nov 2022 16:32
I can't see anything in the Record Civil Registration Data (UK) DEA script that performs any prompts or uses IUP HWND.
It certainly does not use the FH API fhPromptUserForRecordSel(...)
It's in the fhUtils GetParam function.
Code: Select all
local function getParam(sTitle, sTopMessage, fields, tButtons, shortcuts, hParent)
local dlg
[[snip]]
local ptr = fhPromptUserForRecordSel(recordtype, 1, dlg.HWND)[1]
[[snip]]
-- Keep on top
parent = iup.GetGlobal("PARENTDIALOG")
if hParent then
parent = hParent
end
if parent then
iup.SetAttribute(dlg, "PARENTDIALOG", parent)
else
iup.SetAttribute(dlg, "NATIVEPARENT", fhGetContextInfo("CI_PARENT_HWND"))
end
iup.SetHandle("getParam" .. tostring(os.time()), dlg)
iup.Popup(dlg)
doResults()
iup.Destroy(dlg)
return fields
Re: Modal window techniques
Posted: 17 Nov 2022 18:01
by ColeValleyGirl
In fact, why not just open the IUP dialog as a modal to start with?
Re: Modal window techniques
Posted: 18 Nov 2022 12:18
by Mark1834
I've been playing with the
fhPromptUserForRecordSel(...) function to check my understanding of how to use the Window handle, and I'm confused...
This is the example in the plugin help
Code: Select all
require("iuplua");
iup.SetGlobal("CUSTOMQUITMESSAGE","YES");
local btn = iup.button{title="click me"};
local dlg=iup.dialog{ iup.vbox{ iup.label{title="Hello"}, btn}, title="Test Click", size="200x200"};
iup.SetAttribute(dlg, "NATIVEPARENT", fhGetContextInfo("CI_PARENT_HWND"));
function btn:action()
tblIndi = fhPromptUserForRecordSel('INDI', -1, dlg.HWND)
if #tblIndi == 0 then
fhMessageBox('User cancelled')
else
for i=1, #tblIndi do
fhMessageBox(fhGetDisplayText(tblIndi[i]), "MB_OK", "", dlg.HWND)
end
end
end
iup.Popup(dlg);
iup.Destroy(dlg);
I understand passing the handle to the Message Box, as it keeps it modal and stops the user interacting with the calling window while open (even if CP omitted this in the other call to fhMessageBox - that's an untidiness that should be reported anyway).
However, it seems to make no difference to how the plugin behaves whether I pass the Window handle to
fhPromptUserForRecordSel or not. Omit that argument, and it still behaves as a normal modal window, providing that you have set the iup 'NATIVEPARENT' attribute. The calling window is completely inactive, even though the controls are not greyed out. That's normal Windows and FH behaviour, so IMO should be kept as it is.
What's the point of passing the handle to
fhPromptUserForRecordSel? It must be for something.
Re: Modal window techniques
Posted: 18 Nov 2022 13:12
by ColeValleyGirl
Mark1834 wrote: ↑18 Nov 2022 12:18
What's the point of passing the handle to
fhPromptUserForRecordSel? It must be for something.
What happens if you have multiple dialogs open at once -- so each has a different parent? Just wondering...
Or maybe setting the NATIVEPARENT attribute is sufficient to create a default value? Would ave to poke around on the IUP mailing list -- I vaguely remember various discussions on the topic from years ago.
Re: Change any Fact plugin
Posted: 18 Nov 2022 14:30
by Mark1834
One of my bugbears with IUP is that so much often comes down to trial and error. It’s probably too much of a niche interest to attract the skilled technical authors who write guides to more common languages and libraries.
Re: Modal window techniques
Posted: 19 Nov 2022 18:07
by Mark1834
I raised it with CP, as there is an apparent inconsistency between what’s written in the plugin help and what actually happens.
First line support couldn’t add much to what is in the help file, but I made some hopefully constructive suggestions about how the help could be restructured to give a better overview of opening secondary windows under IUP. At the moment, it’s very disjointed between the IUP introduction, individual function descriptions and fhUtils(), which I suspect is not widely used, with no overview of what the potential issues are that the new FH7 function arguments are designed to resolve.
It’s a niche requirement so I’m not holding my breath, but my suggestions will be “passed on for consideration”.