Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Message Boxes and Open File Dialogs...

Author
Message
TheOneRing
22
Years of Service
User Offline
Joined: 28th Aug 2003
Location: Right here.
Posted: 2nd Sep 2003 20:14 Edited at: 2nd Sep 2003 20:18
I wrote a simple C++ DLL with a couple of functions for message boxes and open dialogs. Simple. And it works great at the beginning of my DBPro program, or after my main loop.

But, if I use the message box or open dialog anywhere that resides in the main do...loop (i.e. in a function called from the loop), the windows for the message box or the dialog come out 'messed up'. Any ideas?

Here is the image screwed up (the dll is called from a function called from the main program loop):



Here it is working (called before the program loop):



Thanks!
CattleRustler
Retired Moderator
22
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 2nd Sep 2003 20:33
I believe its because dbp has no concept of "system modality"
When a win32 app calls these functions it understands that they are System Modal, meaning stack commands don't get processed until the new window handle is released

-RUST-
CattleRustler
Retired Moderator
22
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 2nd Sep 2003 20:38 Edited at: 2nd Sep 2003 20:41
you may want to pause your loop while these windows are showing and resume when these windows are closed, not sure how to go about that tho.

Maybe others here have an idea/explanation of what's going on
It just seems to me that the loop is continuing while dialog is open and screwing it all up - could be wrong though.



also look into modality in general because there is Application Modal, as well as System Modal. Different dialogs have different properties as far as modality goes.

-RUST-
TheOneRing
22
Years of Service
User Offline
Joined: 28th Aug 2003
Location: Right here.
Posted: 2nd Sep 2003 20:47
Yes, I understand that... And I believe you are correct (at least in part). I tried using a flag that, when set, did not do any processing inside the do..loop. This, however, did not work. It is certianly strange.
CattleRustler
Retired Moderator
22
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 2nd Sep 2003 21:17
Strange indeed.
Maybe others here with experience in win32 app programming and dbp programming can help?

(I develop in vb6/vb.net but just really starting in dbp)

good luck
RUST

(ps: I should have realized that since you wrote the dll in C++ you are well versed in win32app programming - no offense intended)

-RUST-
CattleRustler
Retired Moderator
22
Years of Service
User Offline
Joined: 8th Aug 2003
Location: case modding at overclock.net
Posted: 2nd Sep 2003 21:23
one other thought...

you said your flagging for the open window (I assume with some boolean) to stop processing in the loop, but are you running in the loop-just bypassing process commands? Maybe try completely stopping the dbp program with a WAIT KEY command. Just to see if it comes up correctly. Any key strokes/mouse clicks should be directed to the win32 dialog. Then when you terminate the win32 dialog, press any key to resume the dbp app - just a thought

something like

do
call win32 dll
wait key
(do whatever in dialog and close it)
(focus returns to dbp)
(press key to continue)
loop

also, there are some "blue-something" dlls that someone wrote to use with dbp that supply windows menus and dialogs - forgot the name of it tho.
Someone here will know


-RUST-
OSX Using Happy Dude
22
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 2nd Sep 2003 21:34 Edited at: 2nd Sep 2003 21:36
The problem is the DX and the windowing system are updated correctly (mainly because they dont like each other). You would need to try and call the SYNC command (using IanM plug-ins) to update the display - which in most cases would be hard as you cant get access to any windows message pump.

By the way, I had already dont a dialog open/save routine.


Avatar & Logo by Indi. Come to the UK DBPro Convention in Chichester
TheOneRing
22
Years of Service
User Offline
Joined: 28th Aug 2003
Location: Right here.
Posted: 2nd Sep 2003 21:42
Yes, I assumed you had. I couldn't find it, however. This behavior also occurs with message boxes. I tried your message box DLL plugin. Same problem.
OSX Using Happy Dude
22
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 2nd Sep 2003 22:32 Edited at: 2nd Sep 2003 22:33
Yes, it is a problem with things like that - unfortunately you either have to put up with it or write a native routine. What may help is perhaps minimise the DBPro window, so the dialog window is placed onto the desktop.


Avatar & Logo by Indi. Come to the UK DBPro Convention in Chichester
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 2nd Sep 2003 22:35 Edited at: 2nd Sep 2003 22:37
Can you respost the images - they haven't come out correctly.

Also, have you got the latest version of DBPro? - I had some issues with early versions.

Just to make sure it isn't a system thing - can you try this demo written using my GUI plugin (see sig). If that works OK then I may be able to suggest changes to your plugin to make it work properly.

http://rob.vapournet.com/misc/dialogs.zip (thanks to VapourNET for hosting )



It works correctly when calling the command from withing a function as well.

TheOneRing
22
Years of Service
User Offline
Joined: 28th Aug 2003
Location: Right here.
Posted: 2nd Sep 2003 22:57
I have DBPro patch 5. It isn't just this system. I tried on 2 others, and had the same effect. Your demo worked fine, Rob... What is it that you are doing differently, I wonder?
OSX Using Happy Dude
22
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 3rd Sep 2003 00:03
Possibly's RobK is subclassing all his dialogs, whilst us mere mortals call the WinAPI directly.


Avatar & Logo by Indi. Come to the UK DBPro Convention in Chichester
Shadow Robert
23
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 3rd Sep 2003 02:28
you know personally if you want menu's and dialogs to work seemlessly with DirectX it's far easier (and gives your far more options) to use MFC, as DirectX is developed specifically to utilise them.

Also make sure your not using Multithreading, this can cause some arigh results.
You will also want to make sure that your DLL waits for the Windows Message (WM_) callback rather than relying on your DBP program to pick this up.

Another thing to try is to make sure your DirectX instance is allowing the window to be created as a child using DBP as the parent rather than simply creating a null window, oftenly trying to create a second null window instance can cause problems.

There are a few more things depending on how you've structured your DLL and what language you've used ... but those should be enough to help ya for now.

OSX Using Happy Dude
22
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 3rd Sep 2003 13:56 Edited at: 3rd Sep 2003 13:56
Yes, pretty much as I said...

I wont be re-doing the MessageBox/File dialog windows in MFC, as a) MessageBox is only really for debugging/putting messages at the end of programs and b) the File Dialog stuff has been done by RobK.

When doing dialog windows in MFC, I generally make sure the window cant be moved too (which seems to help).


Avatar & Logo by Indi. Come to the UK DBPro Convention in Chichester
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 3rd Sep 2003 19:06
The dialogs are subclassed in mine. Also, I think, and I'll have to check this when I get back home, but I'm pretty sure I am using some of Delphi's routines to draw some GUI elements rather than Windows' ones.

TheOneRing
22
Years of Service
User Offline
Joined: 28th Aug 2003
Location: Right here.
Posted: 3rd Sep 2003 20:42 Edited at: 3rd Sep 2003 20:43
I did my first attempt in C++ using the good, old-fashioned API. The second attempt I tried in Delphi. Both experience the same issue. I am not, however, subclassing...

And also note: I reproduced the demo you sent, Rob K, using my DLL. Worked just fine. I sense that there is one thing I've done in my DBP code, or perhaps a series of actions, that has made this strange problem occur.
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 3rd Sep 2003 21:21
There probably is something causing it - if you could figure this out it would be useful.

OSX Using Happy Dude
22
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 3rd Sep 2003 21:24
Be worth trying to subclass - thats probably the cause of it.


Avatar & Logo by Indi. Come to the UK DBPro Convention in Chichester
TheOneRing
22
Years of Service
User Offline
Joined: 28th Aug 2003
Location: Right here.
Posted: 3rd Sep 2003 22:04
OK. I took all of the DBP functions leading up to and including the function that called the DLL and made the GOSUBs. Now it works!!! Wierd... I can't seem to explain it.

Login to post a reply

Server time is: 2026-07-24 00:18:26
Your offset time is: 2026-07-24 00:18:26