Multi-monitor dialog positioning bug [patch]

[280Z28]

Dialogs open on the primary display in Windows regardless of which monitor the codeblocks window is open on. Dialogs should open on the same monitor as Code::Blocks is currently displayed on.

This patch fixes the issue. Patch applies using TortoiseSVN in codeblocks/src.

Code

Topic: Multi-monitor dialog position update
Description:
  ! Dialogs would not open on the same screen as the parent dialog when the parent
    is not on the primary display in a multi-monitor Windows environment

I followed the tabs/spaces pattern of each file. In files where I saw that the entire file followed one pattern (say hard tabs) except for one or two lines in a function I updated (that used spaces) I fixed those two lines. In files that were "mixed content" through the file, I left those alone.

If you look at the patch copy in a whitespace viewer, you will see that I was consistent for each file and did not change any patterns.

[attachment deleted by admin]

[280Z28]

By the way, I have just assumed that I'm not supposed to have commit access to the repository. That's why I've just posted patches. If y'all are expecting me to commit my changes you'll have to let me know or it'll never get done.

[killerbot]

vey well done, this is indeed very annoying, if you need to switch monitors because that dialog popped up somewhere else.
Waiting for an svn update where Yiannis applied yoiur changes ......... 

[tiwag]

i've applied your patch to my working copy and it is a big improvement ! thanks

[thomas]

Lol, don't get a wrong idea because I say something opposing every time you come up with something. :lol:

Dialogs should open on the same monitor as Code::Blocks is currently displayed on.

This is very much a matter of taste, and in my opinion not generally true.

It depends how you use your secondary monitor, and on the size of your monitors. I often send a program to the secondary screen when working with two apps (that may even be two instances of Code::Blocks), but I expect message boxes and dialogs to open on the primary screen.
This has a simple biological reason. The main screen is within the central 30° of my field of view, but the secondary screen in the peripheral field. Objects in the peripheral field are not seen as good as the ones in the central field, obviously, so you have to look aside or turn your head.

[280Z28]

Lol, don't get a wrong idea because I say something opposing every time you come up with something. :lol:

Dialogs should open on the same monitor as Code::Blocks is currently displayed on.

This is very much a matter of taste, and in my opinion not generally true.

It depends how you use your secondary monitor, and on the size of your monitors. I often send a program to the secondary screen when working with two apps (that may even be two instances of Code::Blocks), but I expect message boxes and dialogs to open on the primary screen.
This has a simple biological reason. The main screen is within the central 30° of my field of view, but the secondary screen in the peripheral field. Objects in the peripheral field are not seen as good as the ones in the central field, obviously, so you have to look aside or turn your head.

Generally I'm all for customizability, but in this case I'm going to just say that is the wrong action. I use two monitors because I do two different things on two different screens, and the monitor something appears on should be associated with the program I placed there to start with. Having to drag the mouse back and forth and back and forth is extremely irritating. Also, they open in the corner of the main monitor. You may be used to the dialogs always opening on the primary screen, but that is because you've become used to improper program behavior. This program should behave like a every other program and not be the one program to decide to do things differently. It should definitely be changed from the way it is now.

[thomas]

You may be used to the dialogs always opening on the primary screen, but that is because you've become used to improper program behavior.

That is not the case, it is a choice of ergonomy. Which solution is best for you depends on how large your monitors are and where you place them (and what kind of work you do).

This program should behave like a every other program and not be the one program to decide to do things differently.

The decision where a window (or a dialog for that matter) opens should not be the application's choice unless there is a good reason for this. One notable case where making this kind of decision in the application is the window that shows code completion tips. It is of course quite silly to show this window on a display different than the one holding the main window. But for all other cases, it is the window manager's choice where to put a window, not the application's.
Whatever the user prefers (same display, primary display, centered, on top) can be configured inside the window manager (or in desktop settings under MS Windows).

[280Z28]

Can we please let this be a user preference then? I'll go back and change every single line to allow it to be optional, but please, please let there be at least an option for them to open on the same screen.

[tiwag]

...Whatever the user prefers (same display, primary display, centered, on top) can be configured inside the window manager (or in desktop settings under MS Windows).

how does this work i never found a setting in windows which would allow me to specify where a dialog from any program pops up ?
i'm using WinXP SP2

[280Z28]

...Whatever the user prefers (same display, primary display, centered, on top) can be configured inside the window manager (or in desktop settings under MS Windows).

how does this work i never found a setting in windows which would allow me to specify where a dialog from any program pops up ?
i'm using WinXP SP2

You can't

[thomas]

You can't

Yeah right, you can't.

[280Z28]

You can't

Yeah right, you can't.

That's an option in your video card drivers, not a normal one at all.

Edit: Hey, now we see that you have no reason not to patch it now.

[thomas]

Well, I assume you don't run Windows XP using the VGA driver
All mainstream video card drivers for Windows let you do such customizations.
Linux is another story, but there it is the window manager's business.

EDIT:

Edit: Hey, now we see that you have no reason not to patch it now.

Not only do I not have a reason not to patch it, but I really don't want to. If an application explicitely asks for a window to be put onto some display, then it is really placed there. So this would not only have no advantage, but it would actually interfere with the "normal" operation.

[280Z28]

So if I make it an option will you add it?

[thomas]

No objection from my side if it is an option.

What about simple message boxes? Are those consistent with the other dialogs  with your modifications?

[280Z28]

No objection from my side if it is an option.

What about simple message boxes? Are those consistent with the other dialogs  with your modifications?

Not sure which ones are simple. I just changed all the ones that call LoadDialog() in their constructor (since that was easy to search for).

I'll make it an option tonight and post a new patch.

[mandrav]

OK, I haven't stepped in this discussions since I don't really care about the subject (I work on a single monitor setup). So I 'll let you, who have dual monitor setups,  resolve this.

But, 280Z28, do *not* post patches here. They are only going to be lost/forgotten. Patches should be submitted to the patch tracker. That's what we have it for. A forum is *not* a project management tool or medium...

[280Z28]

OK, I haven't stepped in this discussions since I don't really care about the subject (I work on a single monitor setup). So I 'll let you, who have dual monitor setups,  resolve this.

But, 280Z28, do *not* post patches here. They are only going to be lost/forgotten. Patches should be submitted to the patch tracker. That's what we have it for. A forum is *not* a project management tool or medium...

Yeah I just saw that in another thread. I didn't realize you were using it.

[280Z28]

OK I'm ready to make this an option. I need to add the following function to the SDK. Where should I put it, and what class should it be a public member of? I'm thinking Manager.

Code

static void Manager::PositionUserDialog( wxDialog* dlg )
{
    if (user wants dialogs repositioned centered on parent)
    {
        dlg->CenterOnScreen();
    }
}

[thomas]

Code

template<wxDialog* D>PlaceDialog()
{
if(Manager::Get()->GetConfigManager("app")->Exists("/environment/place_dialogs"))
    D->CentreOnScreen();
};

That way, we don't pollute Manager -- this does not belong in there.

EDIT: Don't blame me if I have a typo in there... it is late, and I am falling asleep... But you get the idea

[280Z28]

Code

template<wxDialog* D>PlaceDialog()
{
if(Manager::Get()->GetConfigManager("app")->Exists("/environment/place_dialogs"))
    D->CentreOnScreen();
};

That way, we don't pollute Manager -- this does not belong in there.

What file?

Yeah, it didn't seem to belong to any of the others though. Are you saying just put it the global namespace?

[rickg22]

Hmmm try xtra_classes.cpp - i made that for your custom classes.

Edit: I don't remember the exact name.

[thomas]

But you'd rather put the template in the header, not the cpp

EDIT:
... and you will want to add the void which I forgot, or the compiler won't let you get away.

[280Z28]

But you'd rather put the template in the header, not the cpp

EDIT:
... and you will want to add the void which I forgot, or the compiler won't let you get away.

Yep I was a step ahead of you there. I have this in sdk\xtra_classes.h:

Code

template<wxDialog* D> void PositionUserDialog(bool force=false)
{
    if(force || Manager::Get()->GetConfigManager("app")->Exists("/environment/place_dialogs"))
        D->CenterOnScreen();
}

[rickg22]

Just a question. Why a template?

[280Z28]

Just a question. Why a template?

I actually already made it not a template.

[280Z28]

Why are there sooo manyy blank lines with just trailing spaces in env_settings.xrc?

[280Z28]

Applies cleanly to rev 1524. There are a ton of files updated, so chances of a conflict if this is outstanding for a while is high.

I did not make any changes to surrounding whitespace. I only made the required changes to fix this one bug.

The new option is on the view tab of environment settings.

Sam

[attachment deleted by admin]

[killerbot]

(I work on a single monitor setup).

Dual monitor is superb during coding and debugging. That nasty gui you are debugging is always visible (you drag it on the other screen) and when you hit your breakpoint you can still see it nicely. It helped me a lot in my M$ devstudio gui projects, otherwise the IDE get's focus on the breakpoint or the code you are stepping through and you don't see the GUI window anymore since it's behind the IDE window.

And it is also very nice, to have on a second monitor a Firefox open on the CB page, forum page, so you can check from time to time for the new information.
;-)

I am kinda missing Yiannis's today's changes (well I see them in svn anyway).

Maybe we should buy Yiannis a second monitor for x-mas ...

[mandrav]

Applies cleanly to rev 1524. There are a ton of files updated, so chances of a conflict if this is outstanding for a while is high.

I did not make any changes to surrounding whitespace. I only made the required changes to fix this one bug.

The new option is on the view tab of environment settings.

Sam

Just tell me Sam: how many times do I have to repeat myself about not posting patches in the forums?  :?

[280Z28]

Applies cleanly to rev 1524. There are a ton of files updated, so chances of a conflict if this is outstanding for a while is high.

I did not make any changes to surrounding whitespace. I only made the required changes to fix this one bug.

The new option is on the view tab of environment settings.

Sam

Just tell me Sam: how many times do I have to repeat myself about not posting patches in the forums?  :?

It was late and I'm used to it.  :? Sorry man I sent a PM to thomas. I'll make sure I post my patches on SF from here on! But do you want me to add this one there too, even though it's here now and you've both seen it? I'll do it right now if you want.

[killerbot]

Sam,

do it in sf also.
Then other users can also get it, I'dd also like to build with it, just to test it.
And certainly the print fixes.
I'll just have two CB dirs for building the 'svn' and 'svn+ fixes'. Planning on starting nightly builds also, maybe I can then provide them both.

Lieven

[280Z28]

Sam,

do it in sf also.
Then other users can also get it, I'dd also like to build with it, just to test it.
And certainly the print fixes.
I'll just have two CB dirs for building the 'svn' and 'svn+ fixes'. Planning on starting nightly builds also, maybe I can then provide them both.

Lieven

Ok I did the dialogs one. Print ones I'll post from work today.

[tiwag]

Hi Sam,
i applied your centerdialogs.patch from sf
https://sourceforge.net/tracker/index.php?func=detail&aid=1382498&group_id=126998&atid=707418

and it works almost fine.
A problem are the various progress-bars, which pop up on the main monitor, when i run CB on the second monitor.
i guess this is a wxwidgets-problem, but we have to solve this too.

btw. what wx-version (261 or 262, ansi or unicode) are you using for main development and/or testing ?
i'm currently working still with wx261 (with patch 01) , ansi build.

[280Z28]

Those are bugs in wxWidgets itself. For example, note that CenterOnParent() does nothing at all when the parent is not on the primary display.

Once I get them isolated I'll submit a report to them.

[tiwag]

src/main.cpp:1418

Code

void MainFrame::OnFileOpen(wxCommandEvent& event)
{
    wxFileDialog* dlg = new wxFileDialog(this,
                            _("Open file"),
                            wxEmptyString,
                            wxEmptyString,
                            SOURCE_FILES_DIALOG_FILTER,
                            wxOPEN | wxMULTIPLE);
    dlg->SetFilterIndex(SOURCE_FILES_FILTER_INDEX);

    //PositionUserDialog(dlg);   <-- CRASHES ON  "dlg->CenterOnScreen();"  IF ENABLED

    if (dlg->ShowModal() == wxID_OK)
    {
        wxArrayString files;
        dlg->GetPaths(files);
        OnDropFiles(0,0,files);
    }

    delete dlg;
}

it seems as are some windows-system dialogs not allowed to be CenterOnScreen'ed 

[tiwag]

@280z
any comments ?

[280Z28]

I had given up on this since there wasn't much interest expressed in patching this. I'll take a look again.

[280Z28]

It's clearly a bug in wxWidgets, and it's even more clear that what I stated is the truth. A child dialog should open over the parent, end of story.

Every dialog in wxWidgets calls this when it is created:

Code

CentreOnParent();

The centering bug lies in that code.

My code worked around that by calling:

Code

CentreOnScreen();

which apparently works.

Note the following declarations from wxWidgets-2.6.2\include\wx\window.h:344

Code

        // the generic centre function - centers the window on parent by`
        // default or on screen if it doesn't have parent or
        // wxCENTER_ON_SCREEN flag is given
    void Centre( int direction = wxBOTH );
    void Center( int direction = wxBOTH ) { Centre(direction); }

        // centre on screen (only works for top level windows)
    void CentreOnScreen(int dir = wxBOTH) { Centre(dir | wxCENTER_ON_SCREEN); }
    void CenterOnScreen(int dir = wxBOTH) { CentreOnScreen(dir); }

        // centre with respect to the the parent window
    void CentreOnParent(int dir = wxBOTH) { Centre(dir | wxCENTER_FRAME); }
    void CenterOnParent(int dir = wxBOTH) { CentreOnParent(dir); }

The code for Centre() that handles all of the above functionality is in wxWidgets-2.6.2\src\common\wincmn.cpp:394

I'll do a diff later of the file from the one in the wxWidgets trunk and see if any changes have been made to that code. Now I'm going bowling.

[killerbot]

Very off topic : I went bowling yesterday. 

[Michael]

Very off topic : I went bowling yesterday. 

...I never played bowling .

Michael

[killerbot]

even more off topic : In another thread they were talking about Solitaire plug-in, Freecell ,etc in CB, well maybe a bowling game plug-in might be nice.

Sorry for this of topic crap, just couldn't resist.

[Michael]

even more off topic : In another thread they were talking about Solitaire plug-in, Freecell ,etc in CB, well maybe a bowling game plug-in might be nice.

And before Rick will cut my hands (sorry for overcharging the bandwidth) , let me add a "MyGames" menu in the C::B toolbar to put inside all such nice game plugins .

Michael