Dialogs, a beginner's problems
-
On 01/07/2013 at 11:11, xxxxxxxx wrote:
The .res file holding your descriptions is a text file. It's a static resource.
You can of course change things by overriding methods like GetDEnabling() and GetDDescription().
But this does not change the fact that the .res file is static resource.
And in Python. We don't even have GetDEnabling() available to override.
I consider this to be disadvantage of the .res system.There's been several posts on the forums where someone (including me) has tried to use a .res file to set a description in a GeDialog. And couldn't. Because it's a Node based only description that is not supported by the GeDialog class.
This happens quite regularly to people. And we've discussed it several times.
This is also what I consider to be a disadvantage of the .res system.If you guys don't think these are disadvantages. That's fine.
A lot of this stuff is subjective to personal preferences.-ScottA
-
On 01/07/2013 at 11:13, xxxxxxxx wrote:
Originally posted by xxxxxxxx
disadvantage 1 is simply not true
Looks like that to me, but if you can show / hide controls dynamically using RES files, then there's no disadvantage.depends on the type of the ressource.
1. for dialogs:
there are several ways to do that here. you are not bound to the createlayout method to define a dialog content. you cannot delete an an element specifically (at least i am not aware of a way), but you can flush groups and then rebuild its content with the new values. technically should be hiding possible for elements with the gedialog.sendmessage method, but i have never tried it, as i did never need it. c4d also offers subdialog elements which allow you to dynamically attach other dialogs to a dialog. in the cpp sdk is an example for that (i think its called dialogtest or something like that). last but not least there the loadressource method itself. it does not replace the dialogs resource but appends the passed ressource to the dialogs ressource. so you can load two ressources into a dialog , which will effectively append one resource to the other. very useful if you have common elements for multiple plugins.
2. for descriptions:
for descriptions the mentioned methods obviously won't work. modifying the description is here only possible on a much lower level. there is GetDEnabling on the one hand which allows you to grey out elements and the there is GetDDescription which allows you to do more stuff, but things can get quite complicated. steve (a form member here and the author of xparticles) wrote an excellent tutorial on that topic.
steves blog : http://www.microbion.co.uk/graphics/c4d/cookbook-2.htm
-
On 01/07/2013 at 11:27, xxxxxxxx wrote:
Originally posted by xxxxxxxx
The .res file holding your descriptions is a text file. It's a static resource.
You can of course change things by overriding methods like GetDEnabling() and GetDDescription().
But this does not change the fact that the .res file is static resource.
And in Python. We don't even have GetDEnabling() available to override.
I consider this to be disadvantage of the .res system.There's been several posts on the forums where someone (including me) has tried to use a .res file to set a description in a GeDialog. And couldn't. Because it's a Node based only description that is not supported by the GeDialog class.
This happens quite regularly to people. And we've discussed it several times.
This is also what I consider to be a disadvantage of the .res system.If you guys don't think these are disadvantages. That's fine.
A lot of this stuff is subjective to personal preferences.-ScottA
of course there is GetDEnabling in python , i think you meant GetDDescription which is not wrapped for python. i am also not sure how these methods are disadvantage of file based resources, as they do refer to descriptions where you do not have the option of code based definitions. and about loading ressources : i (almost) never used the code based definitions and had neither problems in python nor recently in cpp. would be a bit surprising in cpp as its the preferred modus operandi by maxon. there is also nothing magical about it, simply use LoadResource().
but i do agree, in the end its is a question of taste and efficiency and you might be better of with code based definitions if you do not want to learn the (fairly simple) res syntax or just have to define two elements.
-
On 01/07/2013 at 12:18, xxxxxxxx wrote:
Originally posted by xxxxxxxx
and the there is GetDDescription which allows you to do more stuff, but things can get quite complicated.
I have already used that one to show / hide elements, I had forgotten it when I wrote my post.
On the other hand, when dynamically creating a layout, things get much simpler. And a modal dialog is active just a short while, to get some user input, so here I find the dynamic approach perfect.
Among the benefits: I can use the same ID for a Static text, as well as for an Edit box, depending on the user wanting to load or save something. And the function for setting the text can be the same, as long as the ID is the same.if(modeReadOnly) { AddStaticText(DLG_TEXT_SELECTED_FILE, BFH_LEFT, 400, 0, "", BORDER_THIN_IN); } else { AddEditText(DLG_TEXT_SELECTED_FILE, BFH_SCALEFIT, 0, 0); } // And then I can use the same method, regardless of mode void FooDialog::SetSelectedFile(Filename filename) { filename.ClearSuffixComplete(); this->SetString(DLG_TEXT_SELECTED_FILE, filename.GetFileString()); } -
On 01/07/2013 at 12:35, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Among the benefits: I can use the same ID for a Static text, as well as for an Edit box, depending on the user wanting to load or save something. And the function for setting the text can be the same, as long as the ID is the same.
you can do that in res files to. you can reuse the same id as often as you want. some elements like groups also accept no ids at all. also IDC_STATIC is always defined and has not to be redefined in the c4d_symbols file again (and should be only used for elements where you do not care about their id).
-
On 01/07/2013 at 13:32, xxxxxxxx wrote:
Originally posted by xxxxxxxx
but i do agree, in the end its is a question of taste and efficiency and you might be better of with code based definitions if you do not want to learn the (fairly simple) res syntax or just have to define two elements.
It has nothing to do with learning the "fairly simple" res syntax.
There's several occasions when you cannot use the .res file on a gizmo in your GeDialog plugin.
I don't remember what they are off the top of my head. But If I remember correctly. I think the custom guis are like that.
So what happens is you end up with having to declare some things the CreateLayout() method that are not using the .res file at all. Even if you wanted to use the .res file. And not .cpp file.
So you end up with a sort of scatter brained code using the .res file for some things. And the .cpp file for others.Maybe you haven't run into this before. But I have.
-ScottA
-
On 01/07/2013 at 13:38, xxxxxxxx wrote:
Originally posted by xxxxxxxx
you can do that in res files to. you can reuse the same id as often as you want.
Have you tested it? If you have one static text, and one edit text, both with the same ID, and then
- use GetDDescription to hide one of them
- use this->SetString(SOME_ID, someText); to set the text
Will that work? I have not tested, but of it works, then both elements should get the text.
-
On 01/07/2013 at 14:14, xxxxxxxx wrote:
well, it depends on what you do define as 'working'. elements pointing to the the same ID will act as one, just like as you would have defined them with one id in code. so you won't be able to distinguish them for command ids or message ids. getddescription is a bit confusing for me that context, as it does refer to descriptions and is different resource syntax/logic.
for using the setter methods, it will always target the first match. so if you have multiple elements you will always need multiple ids. i would be surprised if that is different for code defined dialogs.
-
On 01/07/2013 at 14:44, xxxxxxxx wrote:
Yes, but then I will definitely use the dynamic creation of elements. Because then I create (Add) either A or B, and as long as they use the same ID, the SetString will guaranteed work.
-
On 01/07/2013 at 15:32, xxxxxxxx wrote:
setters will also work for two different resource files targeting the same ids. its the whole point of file based resources.the idea is to load the dialog definition you need / and or construct it with the above described methods (instead of putting the same element twice into one file and (un)hide one). there are of course scenarios were your dialog content has to be so dynamic that is does almost make no sense to use any file based definitions at all. but i guess these are pretty rare.
-
On 01/07/2013 at 23:51, xxxxxxxx wrote:
Couldn't read the whole thread so sorry if this has been claryfied before.
You have to distinguish between descriptions and dialogs! Both (can) use resource files, but they
look completely different! GetDDescription(), GetDEnabling(), etc. are methods that can be overwritten
by a NodeData plugin. And NodeData plugins use descriptions.Originally posted by xxxxxxxx
if(modeReadOnly) { AddStaticText(DLG_TEXT_SELECTED_FILE, BFH_LEFT, 400, 0, "", BORDER_THIN_IN); } else { AddEditText(DLG_TEXT_SELECTED_FILE, BFH_SCALEFIT, 0, 0); }If you want to disable dialogs elements, you can use the Enable() method of the GeDialog class.
If you want a specific region in your dialog to be dynamic, you can use LayoutFlushGroup() to
remove all the elements in a specific group and move the widget-insertion-pointer directly into
this group.I almost always use resource files.
-Niklas
-
On 02/07/2013 at 00:04, xxxxxxxx wrote:
Originally posted by xxxxxxxx
If you want to disable dialogs elements, you can use the Enable() method of the GeDialog class.
If you want a specific region in your dialog to be dynamic, you can use LayoutFlushGroup() to
remove all the elements in a specific group and move the widget-insertion-pointer directly into
this group.
I almost always use resource files.Great, I was not aware of this.
I also use resource files for tags, but for this modal dialog, I found dynamic creation of elements to be perfect.