* Programatic behaviour of iup.toggle & iup.radio

[ChrisRead]

Is there anyone with some experience of using iup.toggle and iup.radio and programmatically setting a toggle (i.e. not a user click in the UI).

In my case I'm restoring a saved context, but while setting the relevant iup.toggle.value of the group to "ON" shows the toggle as selected in the UI, it does not set the iup.radio.value to that toggle control, as occurs if clicked in the UI. I've tried setting the radio value and value_handle explicitly as well, but neither seem to work.

I'm either missing something, doing it wrong, or it does not support doing it.

I have 3 toggles in a hbox in a radio.

[Mark1834]

Have a look at my recent Check for Unlinked Media (FH7) plugin. It does exactly that by saving selections to file at the end of a session, then setting them again next time it loads.

It’s also sufficiently simple that you can get a good overview of the plugin and what it does without having to wade through extensive housekeeping coding.

[ChrisRead]

Thanks, but I'm doing the same as you, and as I said, it's setting the toggle correctly in the UI when I set toggle.value = "ON". The issue is that the radio container that holds the set of exclusive buttons, normally changes its value to the selected toggle such that radio.value is the relevant toggle control. In my case I use radio.value.name to get the name value to know which of the contained toggles is currently selected. In your case as in mine, setting the toggle.value to "ON" is working just fine, but the radio container does not seem to update its value like a user click does.

You are not making use of the radio other than as a container, whereas I am using it to determine which toggle is selected, and it works fine under normal use, but does not seem right when a toggle is set in code.

[Mark1834]

Have you tried running the radio example script in the iup manual? That sets the active element in code, and seems to behave as expected by inserting a simple print(exclusive.value.title) at the end to easily identify the active element.

[ChrisRead]

So, I'm assuming the IUP - Version 3.31 manual (https://www.tecgraf.puc-rio.br/iup/), in which case the radio.lua sample code does nothing of interest beyond showing having two toggles in a radio. So, I believe there must be another manual lurking somewhere with better examples akin to what you allude.

[Mark1834]

That’s the one - it behaves as I expect, but I’m probably misunderstanding exactly what you’re trying to do.

[ChrisRead]

Basically, when you have a radio container with toggles in it, they are exclusive, so if you click one, the existing one will deselect and the clicked one is selected (sorry, but you know that already). The selected toggle becomes the value of the radio container, hence you can access the attribute(s) of the toggle via radio.value. In my case I set the toggle name to something unique (rather than use the title attribute) at creation, and so at any point I can then check the current selection using radio.value.name. When the toggles are clicked in the UI, this works and radio.value.name is what I'd expect. However, setting the toggle programmatically (when restoring saved option), it does not appear to update the radio.value to the toggle that was selected as you might expect, but does show the selected on in the UI.

I hope that makes what I'm doing clearer, but I suspect from where you've been pointing, it's out of the scope of your experience. It just seems like an inconsistent behaviour between the UI and code, and I may have to do a minimal experimental plug-in to test the behaviour to determine if it's me or IUP.

[Mark1834]

Yep - that's how a humble dabbler like me works - formulate a hypothesis, design a simple experiment, and add the observations to my experience...

I tried a simple model plugin saving and reloading the radio.value directly. I don't pretend to understand handles properly, so the bit I found tricky was recording which toggle had been selected, as all you can save to a configuration file is text. However, I found a simple workaround that appears to work as expected, identifying which toggle had been selected from the radio.value and then restoring radio.value on loading to recreate the UI as it was when closed.

I'm sure it's not the "proper" way to do it, so be interested to see your solution when you've figured it out.

[ColeValleyGirl]

If it helps you can add metasata of your iwn to any iup control - just treat it as a table.

[Mark1834]

That’s what I do in my workaround method - store the toggles in an ordered table, and use a custom field with a value set to the table index. It’s then straightforward to store and retrieve state without overly-complex coding. I avoid calling it “name”, as that appears to be used by iup for storing the handle, and field names in controls are not case-sensitive.

It may not be the way a professional coder would do it, but it works and being easier to follow may even be more useful for open-source plugins.

[ColeValleyGirl]

Not quite the same thing, Mark. I just put the custom field in the control itself. To my mind the coding is simpler -- it's just another property of the control.

[Mark1834]

Ok, I just store the table index as I found that easier to use for restoring status as it refers to the selected toggle directly, but there will be many options that work.

[ColeValleyGirl]

True enough about many ways to work.

I store an oldvalue field in the toggle itself, capture it before the toggle changes, and do myToggle. value= myToggle.oldvalue (syntax not checked) if I need to restore it.

[ChrisRead]

OK, a bit of experimentation later...
I was somewhat confused by the apparent sticky behaviour of the radio control, as I'd set its value to be one of the toggles in the declaration. However, when I tried to set the radio.value to one of the other toggles (when restoring), it didn't seem to want to change as I got the same default radio.value back.

So, I removed the inclusion of setting value to a default toggle in the radio declaration, and that then let me change the value as I'd expect (note that it was always changing correctly when clicked in UI). I found that setting a toggle.value to "ON" didn't update the radio.value automatically, so added that in too. Then found I didn't need to set the toggle.value to "ON" as simply changing the radio.value seemed to do that implicitly.

Conclusion, if you use a iup.radio and want to programmatically set which contained toggle control is active:

• Don't set the radio.value to a default toggle in its declaration (it remains nil).
• To set the active toggle, just set radio.value to the required toggle control.

You then don't need to keep separate tables or variables of which is the active toggle, as if you give each a unique name (i.e. NAME="OPT1") in its declaration, you can simply test the value of radio.value.name.

Thank-you to everyone who responded, even though it didn't provide the answer. I think that there seems to be an odd behaviour of the iup.radio if you declare the value in its declaration. At least that's what seems to have occurred, and that distracted me from what was actually the nearly working solution.

[jelv]

Chris, you don't actually need to give the toggles names.

This is the creation code I have with the last option set as the default:

Code: Select all

local tglPlaceOnly = iup.toggle{title = 'Replace just place with suggested place'}
local tglDateOnly = iup.toggle{title = 'Replace just date with suggested place'}
local tglBoth = iup.toggle{title = 'Replace date and place with suggested date and place'}
local tglNeither = iup.toggle{title = 'Don\'t change event'}
local radioAction = iup.radio{
	iup.vbox{
		tglPlaceOnly, tglDateOnly, tglBoth, tglNeither,
		gap = 1, margin = '10x5',
		}
	}
radioAction.value = tglNeither

In a call back (or after the popup but before destroy) you can find out which option is selected like this:

Code: Select all

if radioAction.value == tglBoth then
...