Family Historian User Group

I must be doing something wrong but when testing fh.getParam in my plugin and pushing Close Window (x) the window vanishes (as expected) but the plugin hangs. Only Debug>Break is allowed, but when activated nothing breaks. If I Break again it just says that Break has already been requested.

I had to stop FH to get out of this lockup. What can be done to fix this?

Have you used setIupDefaults() from fhUtils before doing anything with iup? There's a problem with iup which means you need to set a CUSTOMQUIT messaage for it.

setIupDefaults "Turns on CUSTOMQUIT Message and sets the font to match the Property Box font and enables UTF-8 support"

I suspect you mean iup.GetParam(...) and not fh.getParam but correct me if I'm wrong.

If IUP is upset it is quite common for it to hang in an impenetrable loop.
IUP is a multi-tasking OS in its own right and can get stuck in its OS admin loop waiting for an action that never happens.

See FHUG Knowledge Base IUP GUI Builder Hints and Tips.
Have you included:
require("iuplua")
iup.SetGlobal("CUSTOMQUITMESSAGE","YES")

It is also crucially important to get the iup.GetParam(...) parameter string syntax exactly correct.

Mike, getParam is a function in fhUtils, so I'm pretty sure Joop means fh.getParam and your advice is misdirected (although correct if iup was being used 'naked'.)

@Helen I indeed meant fh.getParam and I have not used setIupDefaults() and I'll do it now. Thanks.

@Mike Why did you assume iup.GetParam? Is it somehow preferable to fh.GetParam and if it's worth the trouble of messing with iup?

I did the setIupDefaults() but when leaving the window with X it still hangs. And after my Debug>Break it still hangs (forever) The message is attached.

Any ideas?

Joop, in V6 fhUtils didn't exist and many of us got used to the idiosyncrasies of iup, but it has always been a royal pain in the backside to use, even for simple purposes. fh.getParam is a way of hiding the complexity (once you've done the initialisation step) and creating simple table-driven interfaces.

If you need a more complex dialog, you'll probably need to get to grips with it at some point, but for people who are writing simple plugins, fhGetparams allows them to focus on the logic of what they're trying to achieve, not jumping through the iup hoops. I've found it an enormous timesaver when writing DEAs, and I've generated some pretty complex interfaces in the past.

Joop,

I've resorted to hiding the X button in the past and including an explicit Exit button. As I said, iup can be a real pain.

What does your execution loop look like? (Your main function, probably)

The fh.GetParam part is:

fh.setIupDefaults()

local par = fh.getParam('Change source template', 'Names of the templates to change:',
{{tag = 'oldTemp', label = 'Old template name:', type = 'STRING', value = sOld},
{tag = 'newTemp', label = 'New template name:', type = 'STRING', value = sNew}},
{'OK', 'Cancel'})
if not par.ok then
return
end

The rest of the function is about changing templates of existing sources. All works as expected but for the accidental press of X. How did you manage to hide the X button?

The problem night be that you haven't set the parent dialog handle, which is the last parameter in
Try
after iup.setIupDefaults()

Re hiding the X, you need to do some of the dialog construction manually for that.

Helen, on execution of:

iup.SetGlobal("PARENTDIALOG", fhGetContextInfo("CI_PARENT_HWND"));

it says:

bad argument #2 to 'SetGlobal' (string expected, got light userdata)

Sorry about that.

Try
and then pass hWnd as the last parameter to fh.getParam.

I did this:

local hWnd = fhGetContextInfo("CI_PARENT_HWND");

local par = fh.getParam('Change source template', 'Name of the template to change:',
{{tag = 'oldTemp', label = 'Old template name:', type = 'STRING', value = sOld},
{tag = 'newTemp', label = 'New template name:', type = 'STRING', value = sNew}},
{'OK', 'Cancel'},'', hWnd)

But now FH terminates.

http://pluginstore.family-historian.co. ... l#getParam

The last parameter but one is a table -- {} not ""

is working for me when Run, or when I step through it in edit mode.

When is FH crashing for you?

I used your code fragment (commented out mine and copy/paste yours) but FH crashes again on execution of the fh.getParam.

When I get rid of hWnd it doesn't crash. What should the value of hWnd be? It says (light user data)??

It should be (lightuserdata) -- it's an identifier for the main fh window. (I'm assuming you don't have any other iup dialogs open?)

If it works without the parent window, go with it -- there is a default set within getParam. But does it still crash when you accidentally press the X button?

No, no iup dialogs open. It works ok without the parent windows except for the X button.

When I press that, the dialog disappears but the plugin is still running and everything is frozen. When I do anything I get the question: Do you wish to break? No matter what I do (Yes or No) I can't get out of this situation except for stopping FH in the task manager.

I was thinking of making the plugin available for others, but can't do it now. It's not safe for public use.

What do you think, should I try to use iup.getParam instead?

First of all, does it fail when it's not in debug mode -- i.e. does it fail if you choose to Run it without the debug window open?

(P.S. I have plugins like that fail like that in Debug mode but have been released and work fine for ordinary users).

That makes a difference. When not in Debug mode the X button works ok.

That solves it. thanks!

Did it work in debug mode when you tested the snippet?

What do you think, would other users be interested in this plugin?

I've attached it. You can test it without it changing anything by commenting out: fhSetValueAsLink(pTemplate, pNewTemp).

Joop, it failed in debug mode when I tested the snippet. If I was to guess (and it's only a guess) iup gets confused because the debug window is open in addition to the fh window, and doesn't exit gracefully as a result.

I think the plugin will be of use; however, I can't seem to get it to do anything (and there aren't any plugin changes to undo after it's completed). What am I missing?

I wonder if it would be better to have two dropdown lists for the old and new names, populated from the names of existing source templates? Or to have the fields autocomplete (using the getParam shortcut facility)?

Sorry Helen, my 'code refactoring' was to rigorous especially for the one statement that does the change. It is corrected in this attachment. My testing has been with that statement disabled, that's why I didn't see it myself.

Great suggestion about the 2 dropdown lists. Can that be done with getParam? I am new to the use of getParam, so some guidance would be much appreciated!

Yes it can be done with getParam which supports lists populated from tables. To populate the table look at the example given for the records function in fhutils. Iterate the templates to add the names to a table that you pass as a parameter for the getParam field.

Will look at the plugin tomorrow.

Thanks, enjoy (the rest of) the evening!

I have changed the plugin to use the dropdown list. It's attached.

Ideas for more improvements are welcome.