09-20-2021 05:43 AM - edited 09-20-2021 05:54 AM
why can't I enter more than 100 global values in a SUD file? After I reach the limit when trying to select one variable for one editbox the assigned variable is completely different than the one selected. When I check the list with all the variables the one that I want to assign is not marked as "In use" and I can't change it as "In use" one. I have to specify that the variables are defined as global ones and are more then 100.
09-22-2021 05:39 PM
Hi AutolivRBT_1,
What DIAdem version are you using? Are you saying that you want to make more than 100 associations between a SUDialog control and a global DIAdem variable, all in the same *.sud file? I have to admit, I've never tried to set up that many associations. I mostly stopped using that approach a few years after we switched from *.cod files to *.sud files. The SUDialog control callback functions are super easy to use for that purpose and a lot more visible than a control-variable association.
I've asked around, and no one knew of a pre-set limitation of 100 associations, but no one could say for sure that there wasn't such a limit. I suspect that even if you're completely right, the chances of this being fixed in a future DIAdem version are low, given that this appears to be the first time anyone has noticed it.
Is there someone else out there in the DIAdem-forum-world who's used more than 100 control-variable associations in one *.sud file?
Brad Turpin
Principal Technical Support Engineer
NI
09-22-2021 11:56 PM
Hello Brad,
Thanks for the reply.
The Diadem version is Diadem 2019 Service Pack 1 (64-bit).
I was thinking to attached some .jpeg's thinking that maybe will be more clear my issue.
The Diadem version is Diadem 2019 Service Pack 1 (64-bit).
I have to admit I'm not familiar with "The SUDialog control callback functions". I don't know how to use them.
Any other opinions or suggestions to solve this issue?
09-23-2021 06:36 PM
Hi AutolivRBT_1,
The pictures do help, thanks. Are you able to submit the *.sud file itself and the VBScript that calls it, so we can see that behavior as well? R&D is not aware of a problem of this type, and it's hard to fix what you can't see or test with...
Thanks in advance,
Brad Turpin
Principal Technical Support Engineer
NI