On 12/02/2014 at 01:44, xxxxxxxx wrote:

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

Hi Folks,

sorry to bug the forum with a number of posts so quickly!

I've got a query about opening dialogs. When opening the dialog, we can set a flag for the type of dialog, e.g. DLG_TYPE_ASYNC and etc.

However, there are two flags that are important to my plugin, that don't appear to do as what I need (and as I'd interpreted from the docs). These flags are DLG_TYPE_ASYNC_FULLSCREEN_WORK and DLG_TYPE_ASYNC_FULLSCREEN_MONITOR.

The first little sticking point is that I can't seem to open either flagged dialog without the top toolbar displaying. Is it possible to not display this? What do I set/where do I call something for this if it's possible? What can I look up in the docs?

The second, and main sticking point, is that the FULLSCREEN_MONITOR flag does not cover the full screen. The bottom Windows toolbar is still visible. I have to left click on the top menu bar (that I don't want) and click on the "Full-Screen (Group) Mode" in order for it to cover the entire display including the Windows toolbar (can anyone confirm how this flag behaves on Mac?).

Preferably without using CallCommand() workarounds (if I have to then...), can this second point be executed properly so that it does actually cover the full screen? do I need to do something like manually set the focus to this particular dialog? Something else?

The dialog is called and executed from a registered command plugin.



On 18/03/2014 at 23:39, xxxxxxxx wrote:

Hi Folks,
I'm having a frustrating time getting what I'm after with this one. Everything I try seems to be 'around' what I need, but never completely covers the full requirements.
I've moved on to trying to set a dialog manually by giving it coords etc in the dlg.Open() call, and while I can get the main screen coords using GeGetScreenDimensions(), I can't find any way to work with dual (or more) monitor setups. The screen dimension function mentions multi display setups, but doesn't tell you anything on how to get the information on the multi screen display! That is, how many monitors there are, what their resolution is, what their coords are and which one is the main screen - that kind of thing.
Single monitor setups don't matter, the above mentioned function is enough for that, but my plugin needs to cater for multi-screen displays because of the nature of it, and that function doesn't seem to tell you (or give you) any information needed to work with multi screen displays.
I'm wishing to resolve this quickly as I'm waiting to hear back from someone about possible alpha/beta testing, and would like this to work as expected before the plugin is passed over. Has anyone used this function before? Or can someone elaborate on how we can effectively work with the setting of dialogs and their positions?

On 23/03/2014 at 20:41, xxxxxxxx wrote:

The documentation says

Parameters _<_h5_>_

> Int32 x
>> Screen X coordinates to identify which display information is read (for multi-display setups).
> Int32 y
>> Screen Y coordinates to identify which display information is read (for multi-display setups).

You need to pass coordinates that are located on the second screen to get its dimensions.


On 24/03/2014 at 00:27, xxxxxxxx wrote:

Hi there Niklas,
yeah, I was a bit confused by what the docs said. I read them as a suggestion that the programmer is already in the know of the coords - which defeats the point of trying to get them!!
With regards to the docs, does this mean we return the resolution of the main monitor first, and then use that as a point to test for other resolutions? I.e. first return is 1920x1200, therefore if we test with 1920 as our second test point, and it returns TRUE, then there's another monitor? I'll have to play with this in some code more, but is that the general idea? To run a loop over the given coords and use the return values as the next starting point to test against?

On 25/03/2014 at 01:07, xxxxxxxx wrote:

Ok, further testing seems to show that the return bool on that function is not whether it's found a new monitor, or even if it finds monitor co-ords, but rather whether filling the values was successful. If this is indeed how the function operates, then this is a strange way of making that work in my opinion. The return bool value will always return true regardless of what was run through the function or it's returned values (baring some sort of failure) - which makes working out if another screen exists very clunky. That appears to be what's happening. 
For instance, I have a dual monitor config, but my second screen is a different resolution to the first one, and it's co-ordinates are offset. This means if my first screen is 1920x1200 (with starting co-ords of 0,0), then the second screen does not necessarily start at co-ords 1920x0. So testing for other screens becomes hit and miss because there's no way of getting or knowing what the offset values are. If you pass co-ords to the function that aren't within the boundaries of a monitor that's offset, then it's not picked up!!
Some trixy-dixy code in a for loop with some flexible boundaries is getting me somewhere that's workable for now, but this feels like a very clunky 'hit-n-miss' way of retrieving screens. I appreciate that this kind of thing is probably seldom used, but still, thought it would be worth mentioning anyway.