Improving my C++ addon GUI development workflow

[BenjiDev]

Hello,

My workflow when it comes to developing the GUI part of C++ addons is so bad and cumbersome, surely I am doing something wrong and looking to improve. 

Basically up until now I am just using "fixed" coordinates for the GUI elements the .grc files. So if i have many text edits in a row that have the same height I have to manually edit each text edit in the .grc file. Its not a big problem for me right now but I can imagine it really kills the workflow for bigger addons.

One solution i came up with is just set every x, y, dx, dy to 0:

/* [  1] */ TextEdit 			  0 0 0 0 LargePlain  255
/* [  2] */ SingleSelListView	  0 0 0 0 SmallPlain  0 0 0 0 bottomText
/* [  3] */ LeftText              0 0 0 0 LargePlain  vCenter  Default  ""
/* [  4] */ Button                0 0 0 0 LargePlain  "Select"

And control the positioning and sizing from the C++ side. So i could have a variable for the rowHeight and apply that to multiple items. 

But this is making the .grc file pretty reduntant so I'm at a stage where I am trying to skip it completely.

I have managed to create a dialog that show up correctly without any reference to the .grc file:

	ExampleDialog() :
		DG::ModalDialog(DG::NativePoint{ DG::NativeUnit{0}, DG::NativeUnit{0} }, 300, 500, GS::Guid{ "B0B67956-1354-4C68-8D75-1F018CF882A8" }),
		text{ GetReference(), {50, 50, 100, 100} },

But the GUI elements themselves DG::TextEdit, DG::LeftText etc... does not show up. Perhaps anyone knows how to do work with them without using .grc files? Skipping the .grc file and relying only on C++ would enable me to create my own little GUI layouting system that would solve alot of problems for me.

I have looked at some example addons and it looks like they all are using this fixed positioning "layout system" in the grc as well as the examples on the web:

https://archicadapi.graphisoft.com/archicad-maze-generator-add-on-tutorial-part-2

I have experience with multiple GUI frameworks both on the web and dekstop and all of these provide simple ways of solving layouting problems.  Are there any hidden layouting system for ArchiCad addon development that no one is talking about? 

How do you all get a smooth developing experience developing the GUI for C++ addons?

[poco2013]

Unfortunately I do not have a solution but will offer my experience and sympathy. The GRC file system is a archaic system that was obsolete when first used 40 years ago. However, it does work well but is tedious to use. AFAIK, the GRC file system uses a underlining series of C functions to execute the file format. These functions are poorly documented (familiar??). and are not supported. In fact, I had a few questions, myself, about their use and sent them into the paid developer support site. There was no explanation given and the response was only to not use those functions and only use the GRC system. It seems that this is the only game in town if you need access to the pen set, lines, layers, fills,etc. dialogs. It is unfortunate that Graphisoft would continue to use such a archaic system and is openly hostile to the needs of its developers (but what else is new?).

As a suggestion and only if you do not need the built-in utility dialogs, you might try a Python script which many are now using. Python has a built-in GUI manager (Tkinter) which may be helpful but is also old looking. There are better interfaces for Python now - notably PyQt and PySide which are more modern.  All of these program extensions  have a GUI layout manager but are  not needed as layout is quite easy and can be dynamic.

Using a AddOn and the Python function CommandHandler, you can easily transfer info and commands  back and forth from your dialog to Archicad.

IOW -- don't expect any help from Graphisoft -- Look for alternatives.

[Oleg · Accepted solution]

---

But the GUI elements themselves DG::TextEdit, DG::LeftText etc... does not show up. Perhaps anyone knows how to do work with them without using .grc files?

---

You need to call the Show method for every item created without grc. 

Or to call once the ShowItems method of Panel.

[BenjiDev]

Thanks, it works! Creating the GUI from C++ without relying on the .grc files opens up alot of possibillities.

[BenjiDev]

Hi, thanks for the answer. Yes I believe I've encountered some areas that where not well documented before. And it would be nice if the GRC file format could be replaced with something resembling for example microsoft XAML. I like python but have never used it in combination with ArchiCad, I'll probably check it out at some point. But thanks to Oleg I can create everything in C++ without the .GRC file. So I think that is the way to go in my case.

[Oleg]

I use "grc". I have more 200 dialogs, tabpages, etc in our addon.
I use some hand written tool as primitive UI editor. I did it many years ago using GDL objects 😊
It generates GRC text for dialog and C++ enum for item IDs.

Anyway it is not so simple way. 

PS: I am not sure, but seems not all options are available without grc for some dialog item types.
I dont remember what exactly, so may be I am wrong

[BenjiDev]

That is alot of dialogs, interesting approach