- Component Services – comexp.msc
- Computer Management – compmgmt.msc
- Device Manager – devmgmt.msc
- Disk Defrag – dfrg.msc
- Disk Managment – diskmgmt.msc
- Event Viewer – eventvwr.msc
- Group Policies – gpedit.msc
- Local Security Settings – secpol.msc
- Local Users and Groups – lusrmgr.msc
- Performance Monitor – perfmon.msc
- Resultant Set of Policies – rsop.msc
- Services – services.msc
- Shared Folders – fsmgmt.msc
- access.cpl - Accessibility controls Keyboard(1), Sound(2), Display(3), Mouse(4), General(5)
- appwiz.cpl - Add/Remove Programs
- desk.cpl - Display properties Themes(5), Desktop(0), Screen Saver(1), Appearance (2), Settings(3)
- hdwwiz.cpl - Add hardware
- inetcpl.cpl - Configure Internet Explorer and Internet properties General(0), Security(1), Privacy(2), Content(3), Connections(4), Programs(5), Advanced(6)
- intl.cpl - Regional settings Regional Options(1), Languages(2), Advanced(3)
- joy.cpl - Game controllers
- main.cpl - Mouse properties and settings Buttons(0), Pointers(1), Pointer Options(2), Wheel(3), Hardware(4)
- main.cpl,@1 Keyboard properties Speed(0), Hardware (1)
- mmsys.cpl Sounds and Audio Volume(0), Sounds(1), Audio(2), Voice(3), Hardware(4)
- ncpa.cpl Network properties
- nusrmgr.cpl User accounts
- powercfg.cpl Power configuration Power Schemes, Advanced, Hibernate, UPS (Tabs not indexed)
- sysdm.cpl System properties General(0), Computer Name(1), Hardware(2), Advanced(3), System Restore(4), Automatic Updates(5), Remote (6)
- telephon.cpl Phone and modem options Dialing Rules(0), Modems(1), Advanced(2)
- timedate.cpl Date and time properties Date & Time(0), Time Zone(1), Internet Time (no index)
- sc create [service name] - to add
- sc delete [service name] - to delete
Tuesday, November 29, 2011
31 Windows Shortcuts
Thursday, September 1, 2011
Catch the Bug - 1
After a long time, I am restarting this blog.
Today I am introducing a programming bug.
Look at the pseudo code below.
unsigned long uCount;
unsigned long uMaxVal;
....
....
//uMaxVal assigned some unsigned value here
....
for(uCount = 0; uCount < uMaxVal -1; uCount++)
{
//Do whatever
}
Do you find anything wrong on seeing this simple statements? You thinks the loop will terminates when the uCount value reaches the uMaxVal.
What if uMaxVal value is 0.
You simply says the program control will not enter in to the for loop. But it is false.
What is the value of (nMaxVal -1) when nMaxVal is equals to zero.
If you Answer '-1' it is Wrong.
Since it is a Unsigned Long value, it does not return -1, instead it returns the maximum value of the long datatype. For a 32 bit compiler it returns '4294967295' as a results. So the program control enters into the for loop and it iterates until uCount reaches the maximum value.
So, beware of using unsigned values.
This is not an infinte loop bug, it terminates once the max value but the behavior of the program is undefined.
Today I am introducing a programming bug.
Look at the pseudo code below.
unsigned long uCount;
unsigned long uMaxVal;
....
....
//uMaxVal assigned some unsigned value here
....
for(uCount = 0; uCount < uMaxVal -1; uCount++)
{
//Do whatever
}
Do you find anything wrong on seeing this simple statements? You thinks the loop will terminates when the uCount value reaches the uMaxVal.
What if uMaxVal value is 0.
You simply says the program control will not enter in to the for loop. But it is false.
What is the value of (nMaxVal -1) when nMaxVal is equals to zero.
If you Answer '-1' it is Wrong.
Since it is a Unsigned Long value, it does not return -1, instead it returns the maximum value of the long datatype. For a 32 bit compiler it returns '4294967295' as a results. So the program control enters into the for loop and it iterates until uCount reaches the maximum value.
So, beware of using unsigned values.
This is not an infinte loop bug, it terminates once the max value but the behavior of the program is undefined.
Wednesday, June 29, 2011
Visual Studio 2010 IDE Hangs when menu items are activated
Sometimes, When mouse over the main menu items (File, Edit, View … Window or Help), the IDE hangs. Sometimes, when clicking on the menu item it will highlight or turn completely black.
The same happens when using the keyboard. Alt+F highlights the File menu. Sometimes (after a few seconds) the region that should display the menu will be drawn in a solid color, but the menu is not populated.
On rare occasion (when using the mouse), the menu will populate, but when hovering over a sub-menu item, the item blinks – or is completely erased.
Environment:
I just upgraded from XP to Win7 Enterprise. Installed VS 2010 Premium and SP1.
Attempted Resolution:
devenv.exe /safemode – It happens when VS is running in Safe Mode also.
I have disable Aero – still happens.
Disabled Hardware acceleration via registry: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Avalon.Graphics\DisableHWAcceleration
Have uninstalled and reinstalled Visual Studio and the service pack.
Visual Studio worked properly when I booted the machine in safe mode. (So I assumed there were some conflicts with in one of the many drivers I installed.)
While in Windows -Safe Mode-, I went to Tools->Options. On the options window, under Environment: General I changed the 'Visual experience' settings. I unchecked "Automatically adjust visual experience based on client performance", "Enable rich client visual experience" & "Use hardware graphics acceleration if available".
With these settings, the IDE works perfectly!
Problem resolved.
More info at https://connect.microsoft.com/VisualStudio/feedback/details/675328/vs2010-ide-hangs-when-menu-items-are-activated
The same happens when using the keyboard. Alt+F highlights the File menu. Sometimes (after a few seconds) the region that should display the menu will be drawn in a solid color, but the menu is not populated.
On rare occasion (when using the mouse), the menu will populate, but when hovering over a sub-menu item, the item blinks – or is completely erased.
Environment:
I just upgraded from XP to Win7 Enterprise. Installed VS 2010 Premium and SP1.
Attempted Resolution:
devenv.exe /safemode – It happens when VS is running in Safe Mode also.
I have disable Aero – still happens.
Disabled Hardware acceleration via registry: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Avalon.Graphics\DisableHWAcceleration
Have uninstalled and reinstalled Visual Studio and the service pack.
Visual Studio worked properly when I booted the machine in safe mode. (So I assumed there were some conflicts with in one of the many drivers I installed.)
While in Windows -Safe Mode-, I went to Tools->Options. On the options window, under Environment: General I changed the 'Visual experience' settings. I unchecked "Automatically adjust visual experience based on client performance", "Enable rich client visual experience" & "Use hardware graphics acceleration if available".
With these settings, the IDE works perfectly!
Problem resolved.
More info at https://connect.microsoft.com/VisualStudio/feedback/details/675328/vs2010-ide-hangs-when-menu-items-are-activated
Friday, December 17, 2010
Root Cause Analysis
If I have an unwanted situation which consumes resources and tends to happen in a repeated fashion then there is a possibility that it might be beneficial to figure out what is really causing this situation to occur and remove it so the situation does not occur again. This is generally referred to as Root Cause Analysis, finding the real cause of the problem and dealing with it rather than simply continuing to deal with the symptoms.
This raises several questions:
>>How does one determine which situations are candidates for root cause analysis?
>>How does one figure out what the root cause is?
>>Does the removal of the cause entail less resource expenditure than it takes to continue to deal with the symptom?
Determining Candidates
-------------------------------------
In normal chaotic organizational environments it is often quite difficult to find candidates for root cause analysis because the situations which repeat are either distributed over time so one doesn't realize they are actually recurring, or the situation happens to different people so there isn't an awareness of the recurring nature of the situation. When an organization is using a an automated problem resolution support system, such as SolutionBuilder, it is very easy to determine which situations are recurring with what frequency. Every time a solution is used its frequency counter gets updated, so all one has to do is run reports against the system to determine which solutions are being used with what frequency. Those situations which are recurring with the greatest frequency and consume the greatest amount of resource to rectify are the candidates for root cause analysis.
Finding the Root Cause
------------------------------------
Most situations which arise within an organizational context have multiple approaches to resolution. These different approaches generally require different levels of resource expenditure to execute. And, due to the immediacy which exists in most organizational situations there is a tendency to opt for the solution which is the most expedient in terms of dealing with the situation. In doing this the tendency is generally to treat the symptom rather than the underlying fundamental problem that is actually responsible for the situation occurring. Yet, in taking the most expeditious approach and dealing with the symptom, rather than the cause, what is generally ensured is that the situation will, in time, return and need to be dealt with again.
Consider the specific example of expediting customer orders in an order fulfillment process. The organization has a well defined process for accepting, processing, and shipping customer orders. When a customer calls and complains about not getting their order the most normal response is to expedite. This means that someone personally tracks down this customer's order, assigns it a #1 priority, and ensures it gets shipped ahead of everything else. What isn't realized, until sometime later on, if at all, is that in expediting this order one or more other orders were delayed because the process was disrupted to get this customer's order out the door. What is all comes down to is that expediting orders simply ensures that more orders will have to be expedited later. In systems terms this is a typical "Fixes that Fail" structure which evolves into an "Addiction" structure where the organization becomes addicted to expediting to deal with customer order complaints.
The appropriate response to this situation is to figure out why the order was in need of expediting in the first place. Yet this is seldom done because the task assigned to the expediter was, "get the order shipped!" and that's as far as the thought processes and investigation are apt to go.
To find root causes there is one really only one question that's relevant, "What can we learn from this situation?" Research has repeatedly proven that unwanted situations within organizations are about 95% related to process problems and only 5% related to personnel problems. Yet, most organizations spend far more time looking for culprits than causes and because of this misdirected effort seldom really gain the benefit they could gain from understanding the foundation of the unwanted situation. Consider the following two scenarios.
Scenario # 1
The Plant Manager walked into the plant and found oil on the floor. He called the Foreman over and told him to have maintenance clean up the oil. The next day while the Plant Manager was in the same area of the plant he found oil on the floor again and he subsequently raked the Foreman over the coals for not following his directions from the day before. His parting words were to either get the oil cleaned up or he'd find someone that would.
Scenario # 2
The Plant Manager walked into the plant and found oil on the floor. He called the Foreman over and asked him why there was oil on the floor. The Foreman indicated that it was due to a leaky gasket in the pipe joint above. The Plant Manager then asked when the gasket had been replaced and the Foreman responded that Maintenance had installed 4 gaskets over the past few weeks and they each one seemed to leak. The Foreman also indicated that Maintenance had been talking to Purchasing about the gaskets because it seemed they were all bad. The Plant Manager then went to talk with Purchasing about the situation with the gaskets. The Purchasing Manager indicated that they had in fact received a bad batch of gaskets from the supplier. The Purchasing Manager also indicated that they had been trying for the past 2 months to try to get the supplier to make good on the last order of 5,000 gaskets that all seemed to be bad. The Plant Manager then asked the Purchasing Manager why they had purchased from this supplier if they were so disreputable and the Purchasing Manager said because they were the lowest bidder when quotes were received from various suppliers. The Plant Manager then asked the Purchasing Manager why they went with the lowest bidder and he indicated that was the direction he had received from the VP of Finance. The Plant Manager then went to talk to the VP of Finance about the situation. When the Plant Manager asked the VP of Finance why Purchasing had been directed to always take the lowest bidder the VP of Finance said, "Because you indicated that we had to be as cost conscious as possible!" and purchasing from the lowest bidder saves us lots of money. The Plant Manger was horrified when he realized that he was the reason there was oil on the plant floor. Bingo!
You may find scenario # 2 somewhat funny, and laugh at the situation. It would be better if the situation made you weep because it is often all so true in numerous variations on the same theme. Everyone in the organization doing their best to do the right things, and everything ends up screwed up. The root cause of this whole situation is local optimization with no global thought involved.
Scenario # 2 also provides an good example of how one should proceed to do root cause analysis. Once simply has to continue to ask "Why?" until the pattern completes and the cause of the difficulty in the situation becomes rather obvious.
To Resolve or Not To Resolve
Once the root cause is determined then it has to be determined whether it costs more to remove the root cause or simply continue to treat the symptoms. This is often not an easy determination. Even though it may be relatively easy to estimate the cost to remove the root cause it is generally very difficult to assess the cost of treating the symptom. This difficulty arises because the cost of the symptom is generally wrapped up in some number of customer and employee satisfaction factors in addition to the resource costs associated with just treating the symptom.
Consider a situation where it is determined that it will cost $100,000 to remove the root cause of a problem and only 5 minutes for someone to resolve the situation when the customer calls with the problem. Initially one might perceive that the cost of removing the root cause is far larger than the cost of treating the symptom. Yet suppose that this symptom is such that when it arises it so infuriates the customer that they swear they will never buy another product from you, and will go out of there way for the next year to tell everyone they meet what a terrible company you are to do business with. How do you estimate to lost business cost associated with this situation. And if you think this is a bizarre case, it is not, for I was personally on an "I hate Midas Muffler" campaign for over two years because they screwed up the brakes on my car. In that two years I managed to reach several thousand people because I preached "I hate Midas Muffler" in my TQM classes, and continued to use them as an excellent bad example.
Finally
----------------
Is "Root Cause Analysis" really an appropriate phrase? In this apparently endlessly interconnected world, everything seems to influence so many other things. Seeking the "Root Cause" is an endless exercise because no matter how deep you go there's always at least one more cause you can look for. Might "Actionable Cause Analysis" be more appropriate? I think I'm looking for a cause that I can act on that will provide long term relief from the symptoms, without causing more problems that I have to deal with tomorrow.
Way To VC
This raises several questions:
>>How does one determine which situations are candidates for root cause analysis?
>>How does one figure out what the root cause is?
>>Does the removal of the cause entail less resource expenditure than it takes to continue to deal with the symptom?
Determining Candidates
-------------------------------------
In normal chaotic organizational environments it is often quite difficult to find candidates for root cause analysis because the situations which repeat are either distributed over time so one doesn't realize they are actually recurring, or the situation happens to different people so there isn't an awareness of the recurring nature of the situation. When an organization is using a an automated problem resolution support system, such as SolutionBuilder, it is very easy to determine which situations are recurring with what frequency. Every time a solution is used its frequency counter gets updated, so all one has to do is run reports against the system to determine which solutions are being used with what frequency. Those situations which are recurring with the greatest frequency and consume the greatest amount of resource to rectify are the candidates for root cause analysis.
Finding the Root Cause
------------------------------------
Most situations which arise within an organizational context have multiple approaches to resolution. These different approaches generally require different levels of resource expenditure to execute. And, due to the immediacy which exists in most organizational situations there is a tendency to opt for the solution which is the most expedient in terms of dealing with the situation. In doing this the tendency is generally to treat the symptom rather than the underlying fundamental problem that is actually responsible for the situation occurring. Yet, in taking the most expeditious approach and dealing with the symptom, rather than the cause, what is generally ensured is that the situation will, in time, return and need to be dealt with again.
Consider the specific example of expediting customer orders in an order fulfillment process. The organization has a well defined process for accepting, processing, and shipping customer orders. When a customer calls and complains about not getting their order the most normal response is to expedite. This means that someone personally tracks down this customer's order, assigns it a #1 priority, and ensures it gets shipped ahead of everything else. What isn't realized, until sometime later on, if at all, is that in expediting this order one or more other orders were delayed because the process was disrupted to get this customer's order out the door. What is all comes down to is that expediting orders simply ensures that more orders will have to be expedited later. In systems terms this is a typical "Fixes that Fail" structure which evolves into an "Addiction" structure where the organization becomes addicted to expediting to deal with customer order complaints.
The appropriate response to this situation is to figure out why the order was in need of expediting in the first place. Yet this is seldom done because the task assigned to the expediter was, "get the order shipped!" and that's as far as the thought processes and investigation are apt to go.
To find root causes there is one really only one question that's relevant, "What can we learn from this situation?" Research has repeatedly proven that unwanted situations within organizations are about 95% related to process problems and only 5% related to personnel problems. Yet, most organizations spend far more time looking for culprits than causes and because of this misdirected effort seldom really gain the benefit they could gain from understanding the foundation of the unwanted situation. Consider the following two scenarios.
Scenario # 1
The Plant Manager walked into the plant and found oil on the floor. He called the Foreman over and told him to have maintenance clean up the oil. The next day while the Plant Manager was in the same area of the plant he found oil on the floor again and he subsequently raked the Foreman over the coals for not following his directions from the day before. His parting words were to either get the oil cleaned up or he'd find someone that would.
Scenario # 2
The Plant Manager walked into the plant and found oil on the floor. He called the Foreman over and asked him why there was oil on the floor. The Foreman indicated that it was due to a leaky gasket in the pipe joint above. The Plant Manager then asked when the gasket had been replaced and the Foreman responded that Maintenance had installed 4 gaskets over the past few weeks and they each one seemed to leak. The Foreman also indicated that Maintenance had been talking to Purchasing about the gaskets because it seemed they were all bad. The Plant Manager then went to talk with Purchasing about the situation with the gaskets. The Purchasing Manager indicated that they had in fact received a bad batch of gaskets from the supplier. The Purchasing Manager also indicated that they had been trying for the past 2 months to try to get the supplier to make good on the last order of 5,000 gaskets that all seemed to be bad. The Plant Manager then asked the Purchasing Manager why they had purchased from this supplier if they were so disreputable and the Purchasing Manager said because they were the lowest bidder when quotes were received from various suppliers. The Plant Manager then asked the Purchasing Manager why they went with the lowest bidder and he indicated that was the direction he had received from the VP of Finance. The Plant Manager then went to talk to the VP of Finance about the situation. When the Plant Manager asked the VP of Finance why Purchasing had been directed to always take the lowest bidder the VP of Finance said, "Because you indicated that we had to be as cost conscious as possible!" and purchasing from the lowest bidder saves us lots of money. The Plant Manger was horrified when he realized that he was the reason there was oil on the plant floor. Bingo!
You may find scenario # 2 somewhat funny, and laugh at the situation. It would be better if the situation made you weep because it is often all so true in numerous variations on the same theme. Everyone in the organization doing their best to do the right things, and everything ends up screwed up. The root cause of this whole situation is local optimization with no global thought involved.
Scenario # 2 also provides an good example of how one should proceed to do root cause analysis. Once simply has to continue to ask "Why?" until the pattern completes and the cause of the difficulty in the situation becomes rather obvious.
To Resolve or Not To Resolve
Once the root cause is determined then it has to be determined whether it costs more to remove the root cause or simply continue to treat the symptoms. This is often not an easy determination. Even though it may be relatively easy to estimate the cost to remove the root cause it is generally very difficult to assess the cost of treating the symptom. This difficulty arises because the cost of the symptom is generally wrapped up in some number of customer and employee satisfaction factors in addition to the resource costs associated with just treating the symptom.
Consider a situation where it is determined that it will cost $100,000 to remove the root cause of a problem and only 5 minutes for someone to resolve the situation when the customer calls with the problem. Initially one might perceive that the cost of removing the root cause is far larger than the cost of treating the symptom. Yet suppose that this symptom is such that when it arises it so infuriates the customer that they swear they will never buy another product from you, and will go out of there way for the next year to tell everyone they meet what a terrible company you are to do business with. How do you estimate to lost business cost associated with this situation. And if you think this is a bizarre case, it is not, for I was personally on an "I hate Midas Muffler" campaign for over two years because they screwed up the brakes on my car. In that two years I managed to reach several thousand people because I preached "I hate Midas Muffler" in my TQM classes, and continued to use them as an excellent bad example.
Finally
----------------
Is "Root Cause Analysis" really an appropriate phrase? In this apparently endlessly interconnected world, everything seems to influence so many other things. Seeking the "Root Cause" is an endless exercise because no matter how deep you go there's always at least one more cause you can look for. Might "Actionable Cause Analysis" be more appropriate? I think I'm looking for a cause that I can act on that will provide long term relief from the symptoms, without causing more problems that I have to deal with tomorrow.
Way To VC
Using resources from a DLL
Using Resources from DLL
Requirements:
----------------------
Let us consider we have a DLL named 'FilingResource.DLL' containing resource of Dialog having ID as IDD_NETWORK_PATH_SETUP. We have class CFilingResourceDlg associated with this dialog. We want to import this dialog in the DLL, in our program by inheriting CFilingResourceDlg class with the class CDerivedClass.
Steps to use Resource stored in DLL:
-----------------------------------------------------------
1) Load the DLL using LoadLibrary()
The LoadLibrary function maps the specified executable module into the address space of the calling process. LoadLibrary takes one parameter of LPCTSTR type which points to the null terminated string that names the executable module i.e. the name of the DLL. If the function succeeds, the return value is a handle to the module (DLL in our case).
e.g. HINSTANCE hResourceDLL = ::LoadLibrary(_T(“FilingResource.DLL”));
2) Convert the dialog ID, which is an integer, to resource type so that it can be used with resource related functions.
e.g. LPCTSTR lpszTemplateName =
MAKEINTRESOURCE(IDD_NETWORK_PATH_SETUP);
3) Determine the Resource (i.e. Dialog) in the module (i.e. DLL) using FindResource()
The FindResource function determines the location of a resource (Dialog in our case) with the specified type and name in the specified module (DLL in our case). FindResource() takes three parameters: A Handle to the module, Name of the resource and type of the resource. If the function succeeds, the return value is a handle to the specified resource’s info block.
e.g HRSRC hResource = ::FindResource(hResourceDLL, lpszTemplateName, RT_DIALOG);
4) Load the Resource using LoadResource.
The LoadResource function loads the specified resource into global memory. This function takes two parameters: A handle to the executable module and the resource found using FindResource. If the function succeeds, the return value is a handle to the global memory block containing the data associated with the resource. If it fails, the return value is NULL.
e.g. HGLOBAL hTemplate = LoadResource(hResourceDLL, hResource);
5) Lock the resource in memory using LockResource.
The LockResource function locks the specified resource in memory. This function takes the handle of the resource obtained by LoadResource as a parameter. If the loaded resource is locked, the return value is a pointer to the first byte of the resource; otherwise, it is NULL.
e.g. LPDLGTEMPLATE lpDialogTemplate = (LPDLGTEMPLATE)LockResource(hTemplate);
6) Create object of the class and call InitModalIndirect() and DoModal() of the Dialog.
The empty constructor is called to construct the dialog-box object. Next, InitModalIndirect is called to store the handle to the in-memory dialog-box template. The Windows dialog box is created and displayed later, when the DoModal member function is called.
e.g
CDerivedClass derivedClassObj;
derivedClassObj.InitModalIndirect(lpDialogTemplate);
derivedClassObj.DoModal();
waytovc.blogspot.com
Requirements:
----------------------
Let us consider we have a DLL named 'FilingResource.DLL' containing resource of Dialog having ID as IDD_NETWORK_PATH_SETUP. We have class CFilingResourceDlg associated with this dialog. We want to import this dialog in the DLL, in our program by inheriting CFilingResourceDlg class with the class CDerivedClass.
Steps to use Resource stored in DLL:
-----------------------------------------------------------
1) Load the DLL using LoadLibrary()
The LoadLibrary function maps the specified executable module into the address space of the calling process. LoadLibrary takes one parameter of LPCTSTR type which points to the null terminated string that names the executable module i.e. the name of the DLL. If the function succeeds, the return value is a handle to the module (DLL in our case).
e.g. HINSTANCE hResourceDLL = ::LoadLibrary(_T(“FilingResource.DLL”));
2) Convert the dialog ID, which is an integer, to resource type so that it can be used with resource related functions.
e.g. LPCTSTR lpszTemplateName =
MAKEINTRESOURCE(IDD_NETWORK_PATH_SETUP);
3) Determine the Resource (i.e. Dialog) in the module (i.e. DLL) using FindResource()
The FindResource function determines the location of a resource (Dialog in our case) with the specified type and name in the specified module (DLL in our case). FindResource() takes three parameters: A Handle to the module, Name of the resource and type of the resource. If the function succeeds, the return value is a handle to the specified resource’s info block.
e.g HRSRC hResource = ::FindResource(hResourceDLL, lpszTemplateName, RT_DIALOG);
4) Load the Resource using LoadResource.
The LoadResource function loads the specified resource into global memory. This function takes two parameters: A handle to the executable module and the resource found using FindResource. If the function succeeds, the return value is a handle to the global memory block containing the data associated with the resource. If it fails, the return value is NULL.
e.g. HGLOBAL hTemplate = LoadResource(hResourceDLL, hResource);
5) Lock the resource in memory using LockResource.
The LockResource function locks the specified resource in memory. This function takes the handle of the resource obtained by LoadResource as a parameter. If the loaded resource is locked, the return value is a pointer to the first byte of the resource; otherwise, it is NULL.
e.g. LPDLGTEMPLATE lpDialogTemplate = (LPDLGTEMPLATE)LockResource(hTemplate);
6) Create object of the class and call InitModalIndirect() and DoModal() of the Dialog.
The empty constructor is called to construct the dialog-box object. Next, InitModalIndirect is called to store the handle to the in-memory dialog-box template. The Windows dialog box is created and displayed later, when the DoModal member function is called.
e.g
CDerivedClass derivedClassObj;
derivedClassObj.InitModalIndirect(lpDialogTemplate);
derivedClassObj.DoModal();
Subscribe to:
Posts (Atom)