refnum to StrictTypedef with KeyNavigation "RETURN" steals string ValueChanged event

[chrisger]

Hi there

this is strange:

- Create a StrictTypedef control (e.g. a button) and attach the controls KeyNavigation to the RETURN key

- Create a vi with a String control which input is limited to single line

- Create a refnum to the StrictTypedef (by dragging the StricTypedef control inside the refnum)

- Note: Just create a refnum TO a StrictTypedef control, NOT a StrictTypedef control on the vi

- Now you can't end the input to the string control by pressing RETURN anymore

- See attachment for details

Seen on LV 8.5(.1) on XP and W2000

[DanielHermyt]

Hi chrisger,

what do you want to do? You don't use your StrictTypeDef in your VI, so why do you create the reference to it? Without the reference everything works fine!

Please give us a little bit more information of what you want to do.

[chrisger]

hi there

"You don't use your StrictTypeDef in your VI, so why do you create the reference to it?"

to get read/write acces to the data in that control. the control is a cluster placed on another FP, so i pass the control reference from that vi to the vi with the string control. to avoid broken wires when i change the control type i use a strict typedef control. 

Of course i could pass the data using a control instead of a reference, but i want to have both read and write access, and someone may won't to have acces to more propertys than just the value.

[DanielHermyt]

Hi chrisger,

please excuse my delay, I haven't been at the office regularly in the last weeks.

The behavior is as expected. The return button is defined for the stricttypedef as the key navigation and therefore overrides for the other RETURN-key navigations. Here, the reference is handled as a control with a defined key navigation. (You cannot set the same key navigation to more than one control and for the string control it is by default set to return.)
In your VI, the input to the control isn't finished by clicking the return-button and therefor the event isn't fired.
In that case you have to use different key navigations for your controls, e.g. you could use the tab-button.

[chrisger]

Hi there

lets say:

FP1 holds control C1 and refnum REF(C2)
FP2 holds control C2

User presses C1, so FP1 has focus.

I would not expect that behaviour, because the RETURN is stolen by the refnum REF(C2), NOT the control C2. C2 is placed on FP2 which is NOT in focus, because FP1 has focus.

"You cannot set the same key navigation to more than one control and for the string control it is by default set to return."

Yes, i can set the same key navigation, just in case the two controls are on different FPs, because only one FP has focus at any time, and this is the case.

I just don't get why a refnum catches the controls associated key stroke.

[DanielHermyt]

Hi chrisger,

the refnum, that is placed on FP1, contains the key navigation for C2 as well because it is a refnum to that element wich indicates that C2 belongs to FP1 as well. The refnum contains the properties of the associated control.