Dialog groups

On 08/10/2013 at 17:23, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   R14 
Platform:   Windows  ;   
Language(s) :

---------
Hi Folks,

I have myself a GeDialog. In this I have an AddEditText() field, and I'm having a little trouble keeping the edit field within it's parents group size. If there is more text than the width of the edit field area, the text field/group is scaling up so that all the text is revealed. However I don't want this to happen. If the text is longer than the edit field, I'd like it to simply disappear etc so the user has to scroll along the text themselves.

I'd like this because some text entries are quite long, and the edit field group is making other parts of the dialog too small to work with.

I've tried every combination of BFH_SCALEFIT flags etc that I can think of (including NULL) with both the groups and the edit field, but can't seem to find the right combination. I'm not aware either of any function to use elsewhere (e.g. in the Init()) to keep it under control.

I'm assuming (dangerously) that this is indeed possible to constrain the width of a text edit field in a dialog. I've managed to do it in the AM in the past. Does anyone know the right flags to use in a dialog scenario like this?

  
GroupBegin(ID_GROUP_MAIN,BFH_SCALEFIT|BFV_SCALEFIT,1,0,"",NULL,0,0);   
    GroupBegin(ID_GROUP_GROUP,BFH_SCALEFIT|BFV_SCALEFIT,3,0,"",BFV_GRIDGROUP_ALLOW_WEIGHTS,0,0);   
        GroupBegin(ID_GROUP_BROWSER, BFH_SCALEFIT|BFV_SCALEFIT,1,0,"",NULL);   
            GroupBegin(ID_GROUP_BROWSER_DIRECTORY, BFV_SCALEFIT,1,0,"",NULL);   
               GroupBegin(ID_GROUP_BROWSER_PATH, NULL,3,0,"",NULL);   
                    AddEditText(ID_GROUP_BROWSER_ADDRESS, NULL,0,0);   
               GroupEnd();   
            GroupEnd();   
        GroupEnd();   
    GroupEnd();   
GroupEnd();   

The above layout is a re-enactment (!) of what I have that's relevant to the edit text gizmo. Some groups can be swapped and hidden (including the entire browser group).

Finding the right flag combinations for gadgets etc. feels like fumbling around in the dark at times!

Regards,

WP.

On 09/10/2013 at 06:46, xxxxxxxx wrote:

I think that if you set the initw and inith and use BFH_CENTER|BFV_CENTER (for instance), it will not change when the dialog is resized.

On 09/10/2013 at 19:46, xxxxxxxx wrote:

Thanks Robert, that seems to have made the dialog act like I want it too. Looks like 0,0 for the initw & inith appear to trigger something in the group to make it act a little differently, even with the same flag settings.

Cheers,

WP.

On 14/04/2014 at 19:06, xxxxxxxx wrote:

Hi folks,
 
when dialogs are first opened, where are they getting their settings from - e.g. their initial size? I have a command plugin that opens a dialog, and have set the defaultw/defaulth values in Open() but the dialog is never sized to them. Has this something to do with the general prefs? Or is there a way to see that the dialog is opened to the specified values - i.e. is there something that clears previous dialog sizes I could use/call upon?
 
WP.

On 15/04/2014 at 03:06, xxxxxxxx wrote:

The size of an async dialog is remembered, even when the application is closed and opened again.

On 15/04/2014 at 07:57, xxxxxxxx wrote:

I found a way to force the dialog window to shrink after dynamically removing gimos
Its not pretty. But it works.
https://plugincafe.maxon.net/topic/7783/9995_resize-dialog-after-layoutflushgroupid

-ScottA

On 22/04/2014 at 23:07, xxxxxxxx wrote:

Thanks for the input all.
 
Just a thought, and I don't mean to be a berk about it, but the dialog layout system deployed in Cinema is absolutely useless. Same for the AM layouts as well.
 
WP.

On 23/04/2014 at 08:18, xxxxxxxx wrote:

It's biggest problem is it's age.
I think this stuff we're using now was written way back in the 90's. Before WYSIWYG came into popularity.

I've been able to create my own dialogs and gizmos using Win32 OS code.
It's really fairly simple. You just grab the main C4D window by it's name (I have written special code for that). And make it the parent window.
Then create another window in Win32 code that's a child of the main C4D window. Putting whatever Win32 gizmos you want in it.
But the problem that stops it from working is that C4D does not receive Windows messages. :angry:

I can launch my own Win32 window just like any other dialog plugin from the C4D menu.
But because I can't send messages to C4D from my dialog window. All I can do is execute a C4D command whenever the Win32 window itself is clicked. Not the gizmos.
But things like the window's size itself I can control through my Win32 code.

-ScottA

On 23/04/2014 at 20:54, xxxxxxxx wrote:

Hi there Scott,
 
I'd been wondering about making my own OS related dialog. It would probably be a lot easier. I made myself an intranet application in the hope the plugin development started going somewhere. It took me a few hours to make a dialog in windows work the way I wanted it too.
 
In contrast, after weeks of trying everything under the sun, I cannot get cinema to open and operate a dialog the way a user would expect it too.
 
WP.

On 24/04/2014 at 15:58, xxxxxxxx wrote:

Since the C4D dialog interface isn't WYSIWYG but instead more like general HTML layout, it is difficult to get precise control of elements in the interface.  Groups are a good way to get some control but you still can't put elements at precise locations or give precise sizes (only starting or minimum sizes).

If you are going to try to use C4D dialog elements in a 'non'-C4D dialog, this might be the painful path.  If you can use, say, OS-related dialog elements in an OS-related dialog, all you need to do is make the interface connections between the OS-related elements and the C4D elements in some way (maybe with a dummy, undisplayed dialog as intermediary?).

On 24/04/2014 at 16:23, xxxxxxxx wrote:

I've been searching for an interface connection like that for months Robert.
The main problem I can't get around is that we can't send an OS message to C4D from our OS dialogs.
If I click on any gizmo in my OS dialog. It sends out a generic message that C4D receives. Which I can use to do something like create a cube.
But that's the only message C4D will see. So I can't have more than one gizmo in my dialog sending their own message to C4D like the built-in GeDialog.

The other problem is that my OS dialog fights with C4D for resources.
The cube will get created in the OM. But it won't show up in the scene until I move the OS window around a little bit.
The OS window also seems unstable. Like C4D is fighting with it.

I've done tons of experiments with it. But the results are very unstable.

-ScottA

On 26/04/2014 at 19:53, xxxxxxxx wrote:

For me, I'm not too concerned at whether we have a WYSIWYG system or not, it's more to do with whether or not you can get it to work the way you want it too. I'm happy doing it in plain code, but only if you know what you are hard-coding is reliable and will work. For the plugin I'm making, I've got it close enough to work I guess, but in this day and age, close enough isn't really good enough. If the underlying system is nearly 20-odd years old, then it's of no surprise it doesn't work well. There really shouldn't be any reason why we can't control these things ourselves by now. For a program that is known for it's intuitive and user friendly layout, it is horribly out of touch for the coders to work with!
 
I'll probably stick with cinema's layout for now, but am curious to know how much difference there is between OS' in regards to making dialogs - are win and mac able to use the same system?
 
WP.

On 27/04/2014 at 03:52, xxxxxxxx wrote:

Originally posted by xxxxxxxx

I'll probably stick with cinema's layout for now, but am curious to know how much difference there is between OS' in regards to making dialogs - are win and mac able to use the same system?

WP.

Short answer, very different and no. Building an interface on a PC using Visual Studio and C# is easy and intuitive, and getting the controls working with the code is simple. On a Mac I find it to be confusing and tricky to understand the concept behind how the controls work with the code, but that's just me. Point being though that the resource files created in Windows are of no use at all in Objective C programming on OSX, and vice versa.

Seriously, I would strongly recommend not wasting your time. Just accept that Cinemas's GUI will not allow you to layout your interface *exactly* as you would like it, and learn to live within its restrictions. Once you accept that, it becomes easy enough to get a decent layout.

On 27/04/2014 at 04:42, xxxxxxxx wrote:

Actually, I've found the C4D UI very intuitive and easy to implement,
especially in contrast to other applications/frameworks. But for this
ease of use, you must draw some limitations.

There's still user areas in case you need somethin special ;)

-Niklas

On 27/04/2014 at 07:02, xxxxxxxx wrote:

Originally posted by xxxxxxxx

On a Mac I find it to be confusing and tricky to understand the concept behind how the controls work with the code, but that's just me.

That's because the Mac uses an MVC (Model-View-Controller) pattern which means that the gui 'displays' information, the controller 'gathers' user input, and the model 'stores' the data.  This disconnect can be difficult to design and follow but the advantage is that the data can be changed and displayed in various ways without having to associate it directly with gui elements.

On 27/04/2014 at 19:56, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Seriously, I would strongly recommend not wasting your time. Just accept that Cinemas's GUI will not allow you to layout your interface *exactly* as you would like it, and learn to live within its restrictions.

Bit of a shame win and mac don't use the same 'stuff', but no surprise really. I'm fairly certain I'll stay with Cinema's system - at the moment I don't have much of a choice anyway. I've already had to replace native elements with my own user areas, looks like I'll just have to keep going down that track. A little annoying though given all we're doing is building something that's "almost" already there!
 
WP.

On 28/04/2014 at 03:01, xxxxxxxx wrote:

Originally posted by xxxxxxxx

That's because the Mac uses an MVC (Model-View-Controller) pattern which means that the gui 'displays' information, the controller '<span style="line-height: 1.4;">gathers' user input, and the model 'stores' the data.  This disconnect can be difficult to design and follow but the advantage is that the data can be changed and displayed in various ways without having to associate it directly with gui elements. </span>

On the rare occasions I have developed Cocoa software on the mac, it usually takes several days before I can get my head round the concept. But when that happens, I would have to agree that it is logical enough.

I grew up with Visual Basic in various flavours and then C# so for me the windows way is comfortably familiar. I guess if I'd always been mac programming that way would seem best :-)

On 28/04/2014 at 13:20, xxxxxxxx wrote:

I'm not sure if this is related or not.
But have you guys noticed this job opening: http://www.maxon.net/about/jobs/singleview/article/user-experience-designer-mw.html
I wonder if this has anything to do with Maxon looking for help in possibly updating their ancient SDK GUI stuff?

I can't remember when this was first posted. But it seems like it's been there for a very, very long time.
Maybe even a year?

Maybe they want to update these things.
But they're having a hard time finding a qualified person to do it?

-ScottA

On 30/04/2014 at 22:21, xxxxxxxx wrote:

Not sure if I've seen that one before or not Scott. I wonder if it's a new position or an existing one?
 
WP.