|
You MUST not use the doc, you code your programm around. It only helps you with some routines.
Another approach can be the modeless dialog. There are some samples in the MSDN and maybe in CP.
Try this @ home. (B&B)
|
|
|
|
|
Thanks for the reply !
Unfortunately, I couldn't find any ways to 'code this around'.. Any hints on where I could find such articles ?
Like I described in my opening post, using a CDialog-derived class is NOT an option, unless you can tell me how I can specify a menu resource, a class name and a window name while building the dialog. Does the CDialog have a suitable overridden CWnd::Create for this purpose ?
Greets,
Antti
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
The application I work on can be ran through an automation model via DCOM, which is fine and works well, but it does mean that we must be able to run several instances of the application on one machine. I've found that I can run no more then 10 instances of the application on any given machine (regardless of the resources available to the machine), and this simply isn't enough, so I've been looking into why this is.
I've found that if I create a standard MFC (VC6) MDI app, accepting all the defaults, that that application can only be ran 102 times simultaneously, which seems very odd to me, the machine (according to task manager on WinXP) has plenty of memory available, but I can't open another instance of the application (or any other application, like notepad). When I trace into it with the IDE I find that it either fails on creating the main frame of loading the main menu resource.
So, I was wondering, does anyone know if there is a limit to the amount of resource's / GDI objects / USER objects / handles / threads Windows can open at once? Or am I barking up the wrong tree - can anyone give me a clue as to how I can get my app to run more simultaneous copies? (Note, I can't change the architecture at this stage, I'm stuck with the automation model, management's decision...)
Dylan
|
|
|
|
|
User Object Handles
User objects are one of three categories of objects handled by the Windows NT® and 2000 operating systems. User objects include items such windows, menus, cursors and icons. The other two categories, GDI and kernel objects, are discussed in subsequent sections.
There is a system wide limit of 65,536 user handles per system. According to Microsoft, there is no per-process limit2; however, testing yielded the following results on Windows NT 4.0 SP6a and Windows 2000 SP2:
Operating System Default Limit Maximum
Windows NT No default No per-process maximum
Windows 2000 10000 (0x2710) 10000 (0x2710)
On Windows NT, although it appears that the per-process maximum is theoretically the same the system maximum of 65,536, the actual maximum is dependent on the type of user objects as well as other system resources such as desktop heap (which is discussed later). On Windows 2000, the maximum number of user handles per process can be set in the following registry entry; however, the default value of 10000 (0x2710) seems to also be the maximum value.
HKLM/Software/Microsoft/Windows NT/CurrentVersion/Windows/USERProcessHandleQuota
In Windows 2000, user object handle counts can be monitored via the Processes tab of Task Manager by selecting View->Select Columns... and selecting the "USER object" check box. While this option also exists in Task Manager on Windows NT, it is not functional on that platform.
GDI Object Handles
The Graphics Device Interface is the means by which applications communicate with graphical devices (such as monitors and printers) in a device-independent fashion. GDI objects include pens, brushes, bitmaps, fonts, etc. The per-process defaults and limits for the number of these objects varies between the NT and Windows 2000 operating systems. Additionally, the registry entry where the per-process limit can be set varies slightly; however, that key is found in the HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/CurrentVersion/Windows hive in both operating systems. Details on GDI limits and the registry entry name are provided in the table below.
Operating System Default Limit Maximum† Registry entry (DWORD)
Windows NT 12288 (0x3000) 16384 (0x4000) ProcessHandleQuota
Windows 2000 10000 (0x2710) 16384 (0x4000) GDIProcessHandleQuota
† Although this is a documented maximum, systems become fairly unstable
after about 15000 GDI handles have been allocated.
Like user object handles, GDI handles can be monitored on Windows 2000 via Task Manager. On Windows NT, GDI handle monitoring within Task Manager is unavailable, so some alternative tool, such as ResourceMonitor, is needed to monitor this resource
The final category of Windows objects is kernel objects, which include system level entities like processes, threads, events, mutexes and files. Each process has a limit of 230 (1073741824) kernel objects.
When a client makes a request to a server, a thread is created for that client, and that thread is generally used to execute the client request. The number of simultaneous client requests therefore has an upper bound equal to the number of threads that can be created within a process.
The number of threads a process can create is also limited by the available virtual memory. By default, when a thread is created, it is assigned one megabyte of stack space, therefore, a process can create at most 2028 threads. Thread stack size can be modified using the EDITBIN utility provided with Microsoft Visual Studio.
Desktop Heap
Desktop heap is a memory resource used to store data relating to graphical objects (such as windows and menus) created within an application. Any executable or library that is statically or dynamically linked with USER32.DLL may make use of desktop heap. Due to the interrelationship of user and GDI objects with the desktop heap, limited heap resources can reduce the effective limits on the per-process maximum numbers of user and GDI objects mentioned earlier in this document.
A desktop heap is allocated for each desktop associated with a window station. Each window station contains a default desktop and other optional desktops that might be created programmatically. In turn, each desktop can contain one or more windows. There is exactly one interactive window station (WinSta0) which is created automatically by winlogon.exe process and includes three desktops: the application (default) desktop, the Winlogon desktop and the screen-saver desktop.
Programs defined as services are also associated with window stations. There are three different options for running services, and each of these options results in a different association with a window station.
The combined size of all desktop heaps has an upper limit of 48MB on Windows NT and 2000. If Terminal Server is executing, the 48MB limit is reduced to 22MB. (On Windows XP the desktop heap is configurable to nearly 500MB). The amount of desktop heap assigned to the interactive window station and to window stations associated with services can be configured via a registry setting. The setting resides in the string value at
HKLM/SYSTEM/CurrentControlSet/Control/Session Manager/SubSystems/Windows
The value is a string that contains the following sequence SharedSection=1024,3072,512 (or perhaps, SharedSection=1024,3072, where the third value is not specified). The first parameter specifies the size of the heap common to all desktops. The second parameter is the size of the default heap for the application desktop (namely, the default desktop in WinSta0). The final parameter specifies the default heap size for desktops created as part of window stations associated with non-interactive services. If this parameter is not specified, all non-interactive services will share the same 3MB heap as the application desktop. If the third value is given, each non-interactive service will be assigned a desktop heap of the specified size. The minimum size for this parameter is 128KB. There is no specific maximum; however, given that the available combined desktop heap allocation can not exceed 48MB, the larger this value the fewer the number of non-interactive services that can be supported.
Big, I know, but there's quite abit of info in there.
John Theal
Physicist/Mathematical Programmer
Digital Immersion Software Corporation
Got CAD?
http://www.presenter3d.com[^]
http://www.merlin3d.com[^]
|
|
|
|
|
Thanks very much John, that's really interesting and helpful.
Dylan
|
|
|
|
|
With regards to the CEdit control, what is the multiline proporty and how do I enable it utilizing VC++6?
Thank you
|
|
|
|
|
The style is ES_MULTILINE. To enable it, double-click the edit box you want to modify, click the Styles tab. See the Multiline checkbox?
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Dear All ,
I am developing an application for Windows 2000 using MFC VC++ Version 6.0.
I need to "refresh" the registry whenever somebody opens the registry using Registry editor.
I have done process enumeration to capture the regedit. When ever registry editor opens my program captures this event. After that i need to refresh it.
Is there API to refresh the registry.
Or any other way out to refresh the registry ?
Thankyou.
Regards,
Rohit 
|
|
|
|
|
|
I'm not sure what you mean by "refresh the registry." When a change is made to the registry, it is immediate.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Dear DavidCrow,
I mean to say that i want to programmitically refresh the registry.
I have opened the registry and now i want to refresh the registry from my program. ie. Something like sending command from SendMessage.
SendMessage(
HWND_BROADCAST, // handle to destination window
WM_COMMAND, //message
WPARAM wParam, // first message parameter
LPARAM lParam // second message parameter
);
I donot know what parameters to send WPARAM and LPARAM.
I suppose we can do it from SendMessage.
Regards,
Rohit
|
|
|
|
|
Once you have Regedit's window handle, try:
SendMessage(hWnd, WM_KEYDOWN, VK_F5, 0);
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Dear DavidCrow,
Thanks , i used in
SendMessage(WM_KEYDOWN, VK_F5, 0);
SendMessage(WM_KEYUP, VK_F5, 0);
my MFC application and it worked perfect.
........
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
Answer: 5
Am i correct ??
..........
Regards,
Rohit
|
|
|
|
|
Insufficient information, needs clarification.
Depends on ones interpretation of the information.
|
|
|
|
|
Dear AORD,
I got the right answer by DavidCrow.
Can you please let me know what else you need to know about the question. I hope it is quite clear. Still if you need some more clarification i can send it .
Rohit
|
|
|
|
|
Sorry I did not make it clear, that my response was regarding the number of birds left on the fence. 
|
|
|
|
|
Dear AORD.
Thanks AORD, I thought that my question was not clear.
Rohit
|
|
|
|
|
Hi,
I have a MFC based application,in that i am getting the following error:
First-chance exception in mytest.exe (KERNEL32.DLL): 0xE06D7363:
Microsoft C++ Exception.
at
m_str=new double[m_width*m_height]
where m_width=256 and m_height=256;
Could anyone help me solve this problem?
Regards
Neha
|
|
|
|
|
It should work assuming m_str is defined as
double *m_str;
|
|
|
|
|
Yes,it is double *.
It is there in a algorithm which is repeatedly been called.
It works fine for first 3 times,4th time it gives that exception message.
If i press F5,then it will show up some assemply code,then if i press F5,it quits my application.
|
|
|
|
|
Are you deleting m_str before you call new again?
delete [] m_str
It still shouldn't crash even if you did not delete it. It would just cause a memory leak. Maybe the problem is somewhere else in your code and not the call to new.
Maybe you could post a little bit more of you code.
|
|
|
|
|
Yes, I do check for the existance of the object,if it is there then i will delete it before doing new.
I run my program through Bouncechecker application, there is no memory or resource leaks.
Even i think problem is somewhere else. But always exception occurs at that stmt.
Code is too huge to post here.
What puzzel's me is it works fine for first 3 times,4th time it throws the exception.
|
|
|
|
|
Neha wrote:
Yes, I do check for the existance of the object,if it is there then i will delete it before doing new.
How are you checking for the existence of the object? Chances are
that this is causing the problem and you are trying to delete an object that does not exist.
John Theal
Physicist/Mathematical Programmer
Digital Immersion Software Corporation
Got CAD?
http://www.presenter3d.com[^]
http://www.merlin3d.com[^]
|
|
|
|
|
I have done like this:
if(m_str!=NULL)
{
delete [] m_str;
m_str=NULL;
}
|
|
|
|
|
Hrm - the only problem I could see with that is that if the object that m_str is pointing to has lost scope, then m_str would not be NULL and calling delete on m_str could cause the exception...
Just thought of something else...are you initializing m_str to NULL??
John Theal
Physicist/Mathematical Programmer
Digital Immersion Software Corporation
Got CAD?
http://www.presenter3d.com[^]
http://www.merlin3d.com[^]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
