* Modal window techniques

[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.

[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.

[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.

[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).

[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.

[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 1254 times

The PLugin window is totally unsuable.

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
 
 

[ColeValleyGirl]

In fact, why not just open the IUP dialog as a modal to start with?

[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.

[ColeValleyGirl]

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.

[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.

[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”.