aero with msgbox MB_YESNO

[Bill Scharf]

We have found some strange behavior for Vista using the Aero theme. Sample could not be simpler:

FUNCTION PBMAIN () AS LONG

    MSGBOX "test",%MB_YESNO, "test title"

END FUNCTION

If you run this with any other Windows OS or any other theme in Vista, the "X" button at the top right is disabled. It is grayed out and clicking on it does nothing--the button cannot be depressed. However, if you run this in Aero, the button is enabled. Clicking on it will still do nothing, but the button can be depressed.

Does anybody know why this is or have any thoughts? It will be annoying to have to create my own msgbox functions just because of this tiny issue.

Thanks!

[Clay Clear]

I believe this is 'by design' (Microsoft's design (Windows messageboxes), not PB's design). If you think about it logically, a messagebox being displayed with a 'yes' and a 'no' choice probably shouldn't be able to be closed with the system menu. That would quite likely mess up the program author's code as far as handling the return of the messagebox function. If you do a little experimenting, I believe you will see that the 'x' button *is* enabled if you use %MB_OK. With that flag, there is no real coding needed to handle the messagebox's return, and it seems logical to be able to close it with the 'x' button if the user wants to.

Make sense?

[Bill Scharf]

Clay,

Thank you for your response. I agree that it is M$'s design to not allow the user to close the msgbox window. My issue is that the button is *not* disabled in the Aero theme like it is in all other Windows OS's. The button is clickable and can be clicked on. No action is taken, but the button is still enabled and clickable. Is this an M$ bug? Is this by design? If so, what is the purpose of changing it for Aero?

[Clay Clear]

Myself, I'll chalk it to up to yet more MS idiocy. Other than that, I don't know enough about it to attempt an answer. Is talking to an MS rep an option for y'all, assuming this issue is that important to you?

Personally, I've been using my own custom 'messageboxes' that I wrote myself years ago. I find it extremely more flexible/configurable that using the standard Windows messageboxes. My personal opnion is that you should take this route, also. It'll mean a lot more work in the beginning, but the high degree of control over what happens makes it worthwhile, IMO.

[Michael Mattias]

>MSGBOX

MSGBOX is a PB function. PowerBASIC Inc is responsible for its behavior, not Microsoft.

[Bill Scharf]

Michael,

You are correct as usual. However, I was under the impression (perhaps incorrectly) that PB's msgbox function was a wrapper to a messagebox API call. I could be wrong. However, if that is the case, I am not sure if it is something that PB has control over. That is why I started this thread. Is this something that PB can control or is this a MS issue? That was why I started this thread in the beginning instead of emailing PB support.

[Michael Mattias]

... I was under the impression (perhaps incorrectly) that PB's msgbox function was a wrapper to a messagebox API

You could be right. You could be wrong. Heck, you could be right for one version of the compiler and wrong for another.

But what's the difference? MSGBOX is MSGBOX is MSGBOX.

MCM

[Dave Biggs]

Easy enough to test.

 
DECLARE FUNCTION MessageBox LIB "USER32.DLL" ALIAS "MessageBoxA" _
  (BYVAL hWnd AS DWORD, lpText AS ASCIIZ, lpCaption AS ASCIIZ, BYVAL dwType AS DWORD) AS LONG
 
FUNCTION PBMAIN () AS LONG
 
    MessageBox 0, "test", "test title", %MB_YESNO
 
END FUNCTION

[Cliff Nichols]

But what's the difference? MSGBOX is MSGBOX is MSGBOX.

Not quite so...

It is up to the compiler (or ultimately the application specific) to be correct to bridge the gaps from one passing to another.

MSGBOX is well know across multiple languages, and its core point is to show you a window with whatever you passed to it.

That said, its up to the language (or more to the point the programmer that wrote the function) to show it correctly

The sad part is, lets say in this case the X comes into play...sure it could close, be disabled, or etc...but last I knew even M$ said the proper way to close a window is not the X....but lets face it, when is the last time you did not close a window that annoyed you and reach immediately for the X??

I think in this case M$ is responsible for documenting changes that PB may not be aware of (or code not shown, as it may be programmer error)

Usually when something this minor (and yet MAJOR becomes aligning the stars and achieving the age of aquarius sort of thing

[Michael Mattias]

It is up to the compiler (or ultimately the application specific) to be correct to bridge the gaps from one passing to another.

The compiler, yes. The application, no.

MSGBOX is well know across multiple languages,

No it's not. 'MSGBOX' is a PB-specific function.

and its core point is to show you a window with whatever you passed to it.

Its purpose is whatever the publisher (PowerBASIC Inc) documents it to be.

That said, its up to the language [publisher]..

Yes.

[Bill Scharf]

Thank you all for your input. To answer Dave Biggs--yes the same result happens when I reference user32.dll directly. Also this will provide the same result:

MessageBox %HWND_DESKTOP, "Text", "Caption", %MB_YESNO

[Roger Garstang]

The only issue I've had related to PB's message box was when calling it from a thread and making it modal. It seems to get a funky icon and not be modal (I can still click and use my form). It seemed to be a glitch in the Windows API call though in how the parent is passed to it. PB I'm guessing follows the docs, but when called from a thread it behaves backwards. I was able to get it to work with the API call, but PB would have to do some checking behind the scenes to do it. Needless to say, the API is full of quirks.

[Michael Mattias]

The only issue I've had related to PB's message box was when calling it from a thread and making it modal. It seems to get a funky icon and not be modal (I can still click and use my form). It seemed to be a glitch in the Windows API call though in how the parent is passed to it.

The funky icon I don't know about, but the fact the MODAL dialog does not disable the parent (owner) is for sure not a Windows error, it's a programmer error with a charge of being an accomplice to the crime levied against PowerBASIC Inc.

No window may be a child of (owned by) a window owned by another thead of execution, ever.

MCM

[Roger Garstang]

"All top-level windows belonging to the current application are disabled until the MSGBOX is dismissed."

No mention of that here...

It does mention a little about it in the API documentation though:

"Same as MB_APPLMODAL except that all the top-level windows belonging to the current thread are disabled if the hWnd parameter is NULL. Use this flag when the calling application or library does not have a window handle available but still needs to prevent input to other windows in the calling thread without suspending other threads."

I'm not at the PC with the code at the moment, but I did get the app to work with the API version. I think the weird icon went away too, I'm not for sure. I'll have to try it with the new compiler and the API again to see the results. It all had to do with how the parent was set...either null or with one specified, so internally PB would need to see if the parent that is set is in another thread and set the parent accordingly...or give us the option to specify parent. I understand what you are saying about a child, but neither one of the documents on the command really mention a parent/child relationship...just that the windows are disabled.

[Roger Garstang]

As for the original issue...the only way I see of making the messagebox behave the same without making your own would be a hook to watch for the messagebox creation and to get the System Menu handle so you can disable/remove Close...then it should disable the button too (usually, sometimes I have mixed results with disabling/removing certain options in the System Menu). You could also find a way to determine the style to only disable it for that type of box, but that is up to you.

Another option using the hook would be to just disable the System Menu and buttons all together and just have a plain Titlebar with the Text.

[Michael Mattias]

"All top-level windows belonging to the current application are disabled until the MSGBOX is dismissed."

Sounds like a bug in MSGBOX to me... observed behavior does not equal documented behavior.

As I am fond of saying, there is either a bug in the compiler or a bug in the documentation, but a bug there is.

MCM