You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
I think Walts question is one that is asked often (on a smaller scale) and Edwins answer is more what really happens...you just do not see it unless looking for it
Although Edwins post gives me a better idea for "What the heck is this post????)
Engineer's Motto: If it aint broke take it apart and fix it
"If at 1st you don't succeed... call it version 1.0"
"Half of Programming is coding"....."The other 90% is DEBUGGING"
"Document my code????" .... "WHYYY??? do you think they call it CODE? "
Well, here's the problem (I don't know whether it's a DDT related or windoz style related), and I've never done this before:
I created two DDT dialogs, the first with hwnd_desktop as the parent and the second with the first as the parent. The second does not have the topmost style. The second is larger than the first. Moving the second from on top the first, the first appears disabled, and when clicking on it, it is indeed disabled, i.e., I can't get it to move to the foreground. So I thought that if I can figure out what message is sent when I click on it I can send setactivewindow to bring it to the top.
I think lbuttondown is the way to go, find the location of the cursur, then send setactivewindow.
the first with hwnd_desktop as the parent and the second with the first as the parent
If the second dialog is a child of the first, and the display is MODAL, the first dialog is disabled by design until the second is dismissed, and no message is going to change that. (code not shown). (well, maybe one "could" make it work, but I would wager you would just be introducing other problems).
Better I think to make both dialogs MODELESS and control which one is on top with SetWindowPos or even Show/Hide the window currently not active (DIALOG SHOW STATE, I think?) ... kind of like you do with a TAB control.
The second dialog does not have the ws_child, ds_control, ws_ex_appwindow, or ws_ex_topmost properties. I created the two like this:
pseudo code
Code:
'================== first dialog ============================
DIALOG NEW %HWND_DESKTOP, title$, x&, y&, xx&, yy&, style&, exstyle&, TO hDlg
'================== second dialog ==========================
DIALOG NEW hDlg, title$, x&, y&, xx&, yy&, style&, exstyle&, TO nDlg
Both are modal.
I guess because I made the owner of the second window the first window, it automatically became a child of the first. I'll play with it a bit and see what I can come up with. Perhaps, Michael, just making the second modeless will cure the problem.
Modal means here that the last window being made modal is enabled.
A reference to a parent does not mean it will be a child but the new window will remain above that one.
Side effect is that due modal the 'parent' will be made disabled.
(This is not the case in SDK mode)
Yes, if you need user interaction in two windows at the same time, you'll need to make all windows modeless except one to handle the messages.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Tweet
Comment