wpw_wapi_res_95.html

VC programing

Close Proximity: "HEY YOU !!!"

The opinions expressed above are entirely personal and do not
reflect the corporate policy of DEC or the opinions of DEC management.
-----------------------------------------------------------------------

<HR>
On 16 Jun 1995 11:31:59 GMT, Jon Jenkins <[e-mail]> said in article <3rrq3f$[e-mail]>:
>
>These are detailed in the series of articles in comp.lang.pascal
>if interested. I think the real questions are:
>
>1: Is there a third "secret" 64k heap used by Windows 
>
>2: Where is the text for a TEdit (or an Edit control) stored.


The text is stored in the local heap unless you trick it by using an 
hInstance handle that refers to a global memory block that is not the 
program's data segment.  The local heap is limited to 64K - size of stack
- size of global data.

Normally, this is not a problem with the Windows dialog box manager code, 
since it will automatically store edit control text in separate global 
memory blocks, unless the DS_LOCALEDIT style is used for the dialog box.  
Delphi may not be as smart, in which case, the text is stored on the 
limited local heap, which is most likely your problem.


--
Robert Mashlan             R2M Software Company           Programmer for Hire
mailto:[e-mail]    http://www.csn.net/~rmashlan     PGP key available
Resources for Windows Developers    -     http://www.csn.net/~rmashlan/windev
Windows Developers FAQ    -    http://www.csn.net/~rmashlan/win-developer-FAQ

<HR>
In article <3s0v3d$[e-mail]>
           [e-mail] "Jon Jenkins" writes:

>Chris Marriott <[e-mail]> wrote:
>>In article <3rrq3f$[e-mail]>
>>           [e-mail] "Jon Jenkins" writes:
>>
>
>Thanks for replying Chris,

My pleasure.

>
>OK. There is a system function GetFreeSytemResources which
>depending upon which parameter you pass can examine any of
>these. Actually there appear to be 3 resource groups
>which this function can analyse:
>
>Name            Size            Function
>System          ???             ???
>User            64k             Window and Menu handles, extra class bytes ??
>GDI             64k             Bitmaps ??
>
>anyone help fill in the table ??

The "System" figure is simply the LOWER of the GDI and USER figures.

>>Every time you create a window space gets used in the USER segment.
>>There is a system-wide limit of the order of a few hundred windows
>>that can be open simultaneously. Remember that every control (such as
>>an EDIT control) is a window and uses space in the USER segment.
>
>Do you know how much space an Edit control uses ? and where the
>text is stored ?

I don't know the exact figure off the top of my head, but the space used
per window is somewhere around 60 bytes. The actual TEXT of the control is
stored in either the application's local heap or the system global heap,
depending on how the application is written.

>This limit of a few hundred windows, do you know where it stems
>from ?

As I said above, it comes from the 64k limit of the USER segment and the
fact that USER space gets allocated whenever a window is created.

>Some applications do not seem to suffer from it. Delphi
>itslef can have 600+ windows open or take a look with Winsight 
>at other large applications with complex toolbars and forms/tab
>sets etc. I have one app (a printed circuit boaord layout) which
>has literally 000s of child windows !! So it appears as tho 
>only SOME applications have this limit. Maybe stuff compiled
>with the MS tools have some secret back door or something. But
>thats what we are trying to find out.

I'm sorry, but that's just not true. The limit of a few hundred windows
applies to ALL applications - there IS no way around it. Applications with
complex toolbars do not - if they have any sense! - use a window for each
button; they use a bitmap. The fact that an application may LOOK as though
it has hundreds of windows doesn't necessarily mean that it does. The only
way to know for sure is using a tool like "Spy".

>>As a matter of design, having more than a few tens of controls on a
>>dialog or form is NOT a good thing. If you need to have a "grid" of
>>EDIT controls, just have ONE control and move it to wherever the input
>>focus currently is.
>
>Dont I know it. However using some modified code from Borland
>we were able to place upwards of 1000 Edit controls on a form.
>The modified code allocated the text storage from the global
>heap.

I find that VERY difficult to believe. The absolute global limit on the
number of windows on the entire system is around 700-ish!

Chris
-- 
--------------------------------------------------------------------------
| Chris Marriott, Warrington, UK      | Author of SkyMap v2 shareware    |
| [e-mail]            | astronomy program for Windows.   |
|      For more info, see http://www.winternet.com/~jasc/skymap.html     |
|      Author member of Association of Shareware Professionals (ASP)     |
--------------------------------------------------------------------------
 
<HR>
In article <3rrq3f$[e-mail]>
           [e-mail] "Jon Jenkins" writes:

>Recently there was a discussion in comp.lang.pascal
>regarding what appeared to be a limit on the 
>number of TEdit controls that could exist 
>within a Delphi application. The debate raged
>as to whether it was a Delphi bug or
>a Windows limitation. Accoringly I
>would like to hear form those who know
>what the real story is:

16-bit Windows has two global 64k heaps - the USER segment and the
GDI segment. The smaller % of free space in these two heaps is what
gets displayed as the "Free System Resources" figure in Program
Manager (and elsewhere) "Help/About" dialog.

Every time you create a window space gets used in the USER segment.
There is a system-wide limit of the order of a few hundred windows
that can be open simultaneously. Remember that every control (such as
an EDIT control) is a window and uses space in the USER segment.

As a matter of design, having more than a few tens of controls on a
dialog or form is NOT a good thing. If you need to have a "grid" of
EDIT controls, just have ONE control and move it to wherever the input
focus currently is.

Regards,

Chris (a guru :-) )
-- 
--------------------------------------------------------------------------
| Chris Marriott, Warrington, UK      | Author of SkyMap v2 shareware    |
| [e-mail]            | astronomy program for Windows.   |
|      For more info, see http://www.winternet.com/~jasc/skymap.html     |
|      Author member of Association of Shareware Professionals (ASP)     |
--------------------------------------------------------------------------
 

</PRE>

<HR><A NAME=WINAPI_RES_FIND_SYS_RES>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: Locating the system resources</H4><PRE>
In article <3rsir4$[e-mail]>
           [e-mail] "Bogdan Pytlik" writes:

>in Windows 3.11 what file contains all system resources, 
>like all cursor shapes etc ?
>
>I checked user.exe,gdi.exe,kernel.exe with appstudio.exe but 
>could not find anything there 

They are in the video driver.

Chris
-- 
--------------------------------------------------------------------------
| Chris Marriott, Warrington, UK      | Author of SkyMap v2 shareware    |
| [e-mail]            | astronomy program for Windows.   |
|      For more info, see http://www.winternet.com/~jasc/skymap.html     |
|      Author member of Association of Shareware Professionals (ASP)     |
--------------------------------------------------------------------------
 
</PRE>



<HR><A NAME=WINAPI_RES_ACCESS>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: Accessing Dialog Resource data</H4><PRE>
In Article<[e-mail]>, <[e-mail]> write:
> 
> In article <3rpv2l$[e-mail]> [e-mail] (Patrik 
Strvmstedt) writes:
> >Is there a way to access dialog resources within a running program?
> >
> >What I'm looking for, is a way to get the x and y coordinates
> >from the controls in a dialog, without display the dialog window...
> >
> >Best Regards,
> >
> >/Patrik
> 
>       FindResource/LoadResource/LockResource
> 
>       After that, you'll need to read up on the format of the dialog
>       structures as described for DialogBoxIndirect().  There is 
also
>       a topic in the on-line help called 'Dialog Box Resource'.
> -- 

There's also an article (Q88680) on Microsoft's Knowledge Base 
describing how the resource is incorrectly documented.  There's an 
extra byte (at least 1, possibly more) at the end of each ControlData 
structure.

Dave
 ____________________________________________________________________
/ If you always do what you've    | David B. Marks                  /\
\ always done, then you'll always | Sandia National Laboratories    \/
/ get what you've always gotten.  | Internet: [e-mail]    /\
\_________________________________|_________________________________\/

</PRE>



<HR><A NAME=WINAPI_RES_Load_Cursor>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: How to load cursor in dialog box?</H4><PRE>
Mueller Beat ([e-mail]) wrote:
: i have the following problem : in my dialog window i want to load one
: of the stock cursors (i.e. idc_arrow). i proceeded this way :

: in setupwindow
: --------------
: oldcursor := loadcursor(0, idc_arrow);
: newcursor := loadcursor(0, idc_cross);
: swtcusor(newcursor);


: but 'newcursor' would not show up ! have i forgotten something seious ?
: or did i miss just a weeny detail ?

The problem is that the dialog box manager code is setting the cursor 
back to the default for you.  See the documentation for the WM_SETCURSOR 
message for a way around this.

</PRE> 

</HTML>