eav@hpindda.HP.COM (Eugene Veteska) (11/22/89)
Hi, I'm having problems with creating a big dialog box. If I create a big enough dialog box, when the box is displayed, most of my conventional memory is eaten up. I have no controls inside the box. As soon as the dialog box is moved, the conventional memory comes back to normal. I ran heapwalker before and after I have moved the box and I find that there is an ~89K non-discardable memory segment that is has been allocated by GDI. When the box is moved, this chunk of memory is freed. This happens on a modeless dialog box (haven't tried it on a modal one) and I can't seem to figure out why this occurs. The problem is when a different dialog box is brought up, Windows hangs or there isn't enough memory to bring it up. Has anyone else had or seen this problem. Here's a copy of my dialog box: TEST DIALOG LOADONCALL MOVEABLE DISCARDABLE 1, 7, 297, 203 CAPTION "Dialog" STYLE WS_BORDER | WS_CAPTION | WS_SYSMENU | WS_SIZEBOX | WS_POPUP | WS_VISIBLE BEGIN END Changing the style flags doesn't seem to help. If I make the box small enough (1, 7, 257, 153) this doesn't occur. Thanks for any help. Eugene Veteska HP Information Networks Division eav@hpindda.hp.com
patrickd@chinet.chi.il.us (Patrick Deupree) (11/27/89)
In article <40130007@hpindda.HP.COM> eav@hpindda.HP.COM (Eugene Veteska) writes: >Hi, > I'm having problems with creating a big dialog box. If I create a big enough >dialog box, when the box is displayed, most of my conventional memory is >eaten up. I have no controls inside the box. As soon as the dialog box >is moved, the conventional memory comes back to normal. We had a customer with this problem a while ago. It seems (if I remember correctly) that Windows treats that dialog box like a bitmap (in some way) and retains the bitmap in memory. When the dialog box is moved, the bitmap is discarded and you have no more problems. I don't remember what exact conditions cause this to happen, but the only solution that our customer came up with was to move the dialog box (as you found). It's kind of a wierd effect since their dialog box will come up and shift over a pixel, but you gotta do what you gotta do. -- "I place my faith in fools. Self confidence, my friends call it." -Edgar Allen Poe Patrick Deupree -> patrickd@chinet.chi.il.us
johnc@plx.UUCP (John C.) (11/29/89)
>>I'm having problems with creating a big dialog box. If I create a big enough >>dialog box, when the box is displayed, most of my conventional memory is >>eaten up. I have no controls inside the box. As soon as the dialog box >>is moved, the conventional memory comes back to normal. If there is enough global memory available to do so, Windows will save the screen contents being obscured by the dialog so it can quickly redisplay them when the dialog is closed. This is controlled by the CS_SAVEBITS class style in the DIALOG class structure. You can disable the "savebits" behavior for the dialog you're opening by clearing the CS_SAVEBITS bit in the dialog's class style, as follows. Do this in the WM_INITDIALOG case of your dialog function, before the dialog becomes visible. Note that since this is a *class* style ("CS_") rather than a window style ("WS_"), this will affect *all* dialogs in the application, and I believe, all dialogs in the Windows session. /* Disable Windows "save dialog background" behavior */ int nDlgClassStyle = GetClassWord( hwndDlg, GCW_STYLE ); SetClassWord( hwndDlg, GCW_STYLE, nDlgClassStyle & (~CS_SAVEBITS) ); [We had to do this in the runtime system of the Plexus XDP product, a 4GL development environment for Windows-based image database applications, because most of our customers are using letter-size (8.5"x11") image fields (controls) in their forms (dialogs). That's a lotta bits to save, and Windows immediately grinds to a crawl unless we turn off CS_SAVEBITS.] /John Ciccarelli
paulkle@microsoft.UUCP (Paul Klemond) (11/30/89)
In article <40130007@hpindda.HP.COM> eav@hpindda.HP.COM (Eugene Veteska) writes: >Hi, > I'm having problems with creating a big dialog box. If I create a big enough >dialog box, when the box is displayed, most of my conventional memory is >eaten up... > ...As soon as the dialog is moved, the conventional memory comes back... > I can't seem to figure out why this occurs. > >Eugene Veteska >HP Information Networks Division >eav@hpindda.hp.com If YOU were writing a windowing package, what would you want to do when you brought a window, especially a "temporary" window like a dialog, up in front of one or more other windows? More importantly, what would you want to do AFTER the window you had brought up went away? Take a look at "CS_SAVEBITS" in the WNDCLASS window class description. This is kind of vague, I know, but the answer lies there. One problem is that this is specified for windows for which Windows saves the maps of, not for the dialog coming to the fore. I'm a little surprised that, if you are correct, the implementation of this doesn't keep the maps at a lower priority for when there is contention for memory. It makes sense for Windows to free them when you move the dialog, but it should free them when you want to open another dialog or window too. That's speaking strictly as a "fellow developer", I haven't looked any of this up in the Windows source... Paul Klemond paulkle@microsoft uunet!microsoft!paulkle Hi, Phil.
eav@hpindda.HP.COM (Eugene Veteska) (12/02/89)
/ hpindda:comp.windows.ms / paulkle@microsoft.UUCP (Paul Klemond) / 8:47 am Nov 29, 1989 / In article <40130007@hpindda.HP.COM> eav@hpindda.HP.COM (Eugene Veteska) writes: >Hi, > I'm having problems with creating a big dialog box. If I create a big enough >dialog box, when the box is displayed, most of my conventional memory is >eaten up... > ...As soon as the dialog is moved, the conventional memory comes back... > I can't seem to figure out why this occurs. > >Eugene Veteska >HP Information Networks Division >eav@hpindda.hp.com If YOU were writing a windowing package, what would you want to do when you brought a window, especially a "temporary" window like a dialog, up in front of one or more other windows? More importantly, what would you want to do AFTER the window you had brought up went away? Take a look at "CS_SAVEBITS" in the WNDCLASS window class description. This is kind of vague, I know, but the answer lies there. One problem is that this is specified for windows for which Windows saves the maps of, not for the dialog coming to the fore. I'm a little surprised that, if you are correct, the implementation of this doesn't keep the maps at a lower priority for when there is contention for memory. It makes sense for Windows to free them when you move the dialog, but it should free them when you want to open another dialog or window too. That's speaking strictly as a "fellow developer", I haven't looked any of this up in the Windows source... Paul Klemond paulkle@microsoft uunet!microsoft!paulkle Hi, Phil. ----------