- This topic has 7 replies, 4 voices, and was last updated 8 years, 2 months ago by
.
-
Posts
-
-
As most of you would probably be aware, the GLOB_ view & project dependent globals will stop working from v20. As this is a pretty big issue for GDL developers, I’m sure there is a workaround solution to this…but I can’t find one. Can someone point me in the right direction (I’ve read the “GDL-Related Changes in ArchiCAD 19” pdf).
E.g. I have parts that read GLOB_SCALE and GLOB_CONTEXT, and want to know what the new methodology should be to retain this functionality…or is it just scrapped altogether?
www.brucepwalker.com
https://www.mindmeister.com/65450406AC20 6005 AUS Full & AC 21 3009 NZE Full | Win 10 Pro 64 | Intel i7-7700HQ 2.80GHz | 16 Gb RAM
NVIDIA GeForce GTX 1060 8Mb -
The restrictions for using these globals only apply to the parameter script, and master script run as parameter script. One of the main reasons is to prevent stored parameter inconsistencies of a placed object in different view settings. The aforementioned globals will work in every other script. Sorry for repeating again, if you meant the same, but I wanted to make sure the parameter/master script only restriction is registered.
Dominika Bobály
Product Manager
GRAPHISOFT SE -
Thanks for that. I can make this work for most of my parts, but there is one I have that allows the user to unlock certain parameters for occasional editing…but re-locks as soon as the user exits the parameters dialog (a sort-of safety mechanism).
Currently, I deal with this by testing for GLOB_CONTEXT <> 5 in the Master Script. I’ve tried this in the 3D and 2D script, but it doesn’t work. I’ve also found that there are reserved keywords UI_OK and UI_CANCEL, but can’t find anything on how to use them.
Not sure how to deal with this one.
Any clues?
www.brucepwalker.com
https://www.mindmeister.com/65450406AC20 6005 AUS Full & AC 21 3009 NZE Full | Win 10 Pro 64 | Intel i7-7700HQ 2.80GHz | 16 Gb RAM
NVIDIA GeForce GTX 1060 8Mb -
For 2D and 3D “preview” in the settings dialog try the GLOB_PREVIEW_MODE global, it has a special value for that (1). This is still not helping in conditional parameter locking, though. Not sure I understand why need to lock certain parameters “outside” the settings dialog, so could you please give some more details?
Dominika Bobály
Product Manager
GRAPHISOFT SE -
Sure: I have developed (beta version anyway) a reasonably complex part that derives its geometry from a set of base parameters. For the most part, these parameters should not have to be, and should not be, altered. But there is the outside possibility that editing would be required.
I dealt with this by locking the parameters, but giving the user the option of unlocking them for editing – a prompt, if you will, that what they were about to do should be done sparingly.
To ensure this ‘safety’ mechanism functioned properly, I re-locked the parameters when the user closed the parameters dialog. This was done by testing the global context. If it wasn’t the parameters dialog, then the parameters got locked.
Attached is a screenshot.
Cheers.
Attachments:
www.brucepwalker.com
https://www.mindmeister.com/65450406AC20 6005 AUS Full & AC 21 3009 NZE Full | Win 10 Pro 64 | Intel i7-7700HQ 2.80GHz | 16 Gb RAM
NVIDIA GeForce GTX 1060 8Mb -
I have a similar problem.
See… https://gdl.graphisoft.com/forums/topic/what-is-the-proper-replacement-for-glob_context1/
I really wish we still had GLOB_CONTEXT.
Barry.Versions 6.5 to 22
Dell XPS- i7-6700 @ 3.4Ghz, 16GB ram, GeForce GTX 960 (2GB), Windows 10
Dell Precision M6800 - i7 4700MQ @ 2.40GHz, 16GB RAM, AMD FirePro M6100 (2GB), Windows 7 64bit -
-
Bruce,
There is no workaround for automatical locking of parameters when settings dialog is closed. We do not want to support this kind of workflow, as this can cause other problems in the program. As we declared earlier – before the release of 19 – context and view dependent information must not be used in parameter script.
Instead of automatic locking, all the objects parameters should be controlled by the script writer: GLOB_MODPAR_NAME, parameters and values commands enables the developer to take control of the possible parameter values and ranges, so in a well written library part geometry should not fail by a user setting.Barry,
The other mentioned problem – GLOB_CONTEXT in the editor – is not the same! We don’t think that “invalid” values should be set in the editor – for these problems you should use the xml source format with the “meaning” technology built in the lp_xmlconverter, which provides the correct values of all parameters in all cases.Gergely Fehér
Team Leader, Library Team
GRAPHISOFT SE
-
- The forum ‘Others’ is closed to new topics and replies.