|
Hi everybody,
I am trying to create dialogs in a loop.
I am having pointer to each dialog and resource id.
Problem is while creating an object of that dialog using new operator.
As new requires the typename which i am unable to provide in a loop.
Please refer the code below.
DlgA *pDlgA;
DlgB *pDlgB;
typedef struct tagDLG_INFO
{
CDialog *pDlg;
DWORD dwDlgID;
} DLG_INFO, *P_DLG_INFO;
DLG_INFO arrDlgInfo[2] =
{
{pDlgA, IDD_A},
{pDlgB, IDD_B}
};
for (DWORD dwLoopCount = 0; dwLoopCount < 2; ++dwLoopCount)
{
arrDlgInfo[dwLoopCount].pDlg = new XXX; //(How to provide typename in a loop).
arrDlgInfo[dwLoopCount].pDlg->Create(arrDlgInfo[dwLoopCount].dwDlgID, this);
}
I tried using macros, templates, RTTI, typeinfo,
but i did'nt find any proper solution.
Thanks in advance.
|
|
|
|
|
If not needed to create a modaless dialog then better to call DoMadal function of CDialog class to create Modal Dialog.
Sushrut
|
|
|
|
|
I am sorry that u didn't get the question.
what i want to do is similar to the following,
float *pf;
float *pf = new float; (This is the normal case where float is the typename passed to new operator).
(Now consider our problem)
int *pi;
char *pc;
If i have such many different types of pointers.
And i want to create memory to that respective pointer with it's respective type in loop.
So how am i able to provide typename to the new operator generically in a loop.
|
|
|
|
|
skmk1247 wrote: arrDlgInfo[dwLoopCount].pDlg = new XXX; //(How to provide typename in a loop).
Does this work for you?
arrDlgInfo[dwLoopCount].pDlg = IDD_A == arrDlgInfo[dwLoopCount].dwDlgID ? new pDlgA(this):new pDlgB(this);
Could also check for NULL
|
|
|
|
|
Your solution is good.
But i had given a sample of code.
What actually i want to do is to create around 20 dialogs of different types.
The resource i can have for this is the array of DLG_INFO.
For acheiving this we can extend or add more members to DLG_INFO.
Thanks.
|
|
|
|
|
|
Yes that is confusing but it is usable.
I'll give you the scenario,
I need to write options/settings module for a product.
The product is dialog based.
Now the options will be in a tree control on the left side.
When user clicks a particular option i need to display appropriate dialog.
There a 20 such options.
To hide or show the respective dialog first they need to be created.
The question i posted doesn't relate to number of dialogs to be created.
Instead, in a loop how can we provide the typename for new operator.
Just refer the root post.
Thanks.
|
|
|
|
|
Perhaps I fail to see what problem you are having. The solution I gave you will work for 2 dialogs or 20 dialogs if you modify it to a switch statement. In addition it should work for any CDialog derived class. What exactly is the problem you are having?
Here are some points:
1.) If your dialogs have a unique dialog resource ID associated with each CDialog derived class then you can easily identify which dialog belongs to which class.
2.) You can assign the CDialog pointer in your DLG_INFO structure to your derived class using the dynamic_cast operator[^] or the STATIC_DOWNCAST[^] macro.
3.) You can regain the type information by upcasting the CDialog pointer to access members.
Maybe I do not fully understand the problems you are having, if this is the case please clarify.
Best Wishes,
-David Delaune
|
|
|
|
|
Your solution was actually very good and convincing.
But i was trying the same without using switch/if-else or any user defined function.
I feel that there may be any other means to achieve the problem.
If it is not feasible then i am really sorry for the question i posted.
Thanks.
|
|
|
|
|
skmk1247 wrote: But i was trying the same without using switch/if-else or any user defined function.
I feel that there may be any other means to achieve the problem.
Yes, there are other ways to accomplish the same thing. You could probably also use a complicated template scheme to accomplish the same thing but why go through all that trouble? Are you attempting this for educational purpose?
Templated code easily produces code bloat if used incorrectly. If you add a template function in the middle of that for-loop it will likely generate much larger code than directly accessing the struct member and generating conditional jump instructions which jmp directly into the class constructor.
There is nothing to gain here by using templated code to create dialogs.
Best Wishes,
-David Delaune
|
|
|
|
|
Yes you are right.
To do that task now i am sequentially writing those many statements for each dialogs.
I thought this task as challenging.
I continued with some research and tryouts.
You have suggested about templates, can you please help me out with a piece of code.
This is just educational.
I haven't stuck for this but I am trying to complete the task in any ways.
Though it is silly problem I have spend enough time for it.
I hope you understood the problem.
Thanks & Regards,
K. Sushilkumar.
|
|
|
|
|
I've had a similar problem in the past.
I used the following article to solve it:
http://secure.codeproject.com/KB/cpp/enumleafclasses.aspx[^]
I created a common ancester for the dialogs
class CMyDialog : public CDialog
{
...
DECLARE_ROOT_CLASS (CMyDialog);
...
};
and then a bunch of inheriting dialogs:
class CMyDialog1 : public CMyDialog
{
...
DECLARE_LEAF_CLASS (CMyDialog);
...
}
Then I could add new child classes to my hearts content - and loop through and create them.
int n, nCount = CMyDialog::GetRegisteredManufacturingPlantCount ();
CBootStrapper<cmydialog> *pBS;
CMyDialog *pSub;
for (n = 0; n < nCount; n++)
{
pBS = CMyDialog::GetRegisteredManufacturingPlant (n);
pSub = pBS->CreateObject ();
....
}
</cmydialog>
You'll need to read the article for fine detail, but I've used the concept a few times, and it worked nicely for me.
I hope that helps,
Iain.
|
|
|
|
|
Thank you.
It is a good solution.
Yes it could help me to some extent in my code.
Because the dialogs are already being implemented.
And i cannot change them from my side.
I can only create the dialogs.
As i discussed in earlier post that i was searching for some different technique instead of using if-else/switch for new operator.
But as part of education/knowledge the technique used is mind blowing.
Thanks & Regards,
K. Sushilkumar.
|
|
|
|
|
If the dialogs are already implemented somewhere else, and out of your control, then the article I pointed you at is of little use.
I don;t think you have any alternative to brute force sadly. You can make it more or less elegant, but at some point you are going to have to match option with dialog...
Maybe populate a map between option DWORD, and CDialog *? then you can iterate a biiiiit.
Iain.
|
|
|
|
|
You need to implement a class factory.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
Hello,
I'm writting a C++ DLL Hook to read any message to any program, so I'm using
SetWindowsHookEx(WH_CALLWNDPROC, CallWndProc, handleInstance, 0);
Then, in my CallWndProc, I need to filter the data coming so I can read the messages from the window I want, but it's not working as expected. During my tests, I wanted to read the messages from the HWND 0x00020afa, so if I put in the CallWndProc:
LRESULT CALLBACK CallWndProc(int nCode, WPARAM wParam, LPARAM lParam)
{
if(nCode < 0)
return CallNextHookEx(handleHook, nCode, wParam, lParam);
CWPSTRUCT* cwpstruct = (CWPSTRUCT*)lParam;
if((HWND)0x00020afa == cwpstruct->hwnd)
{
MessageBox(NULL, "TEST","LOL",MB_OK);
}
return CallNextHookEx(handleHook, nCode, wParam, lParam);
}
I would get the message boxes popping like crazy, but then I decided to add a global HWND to my dll:
HWND hWindow;
And then a stupid function to set it:
VOID __stdcall HookHwnd(HWND hWnd)
{
hWindow = hWnd;
}
So I can choose which HWND i want to track with
if(hWindow == cwpstruct->hwnd) instead of if((HWND)0x00020afa == cwpstruct->hwnd)
... But it doesn't work. Am I doing something wrong here? I'm new to the dll world. Also, is this the correct way to read the messages from a window?
Thanks!
|
|
|
|
|
Hi Tony_P
Whenever you install a hook, the DLL gets injected into the process' memory. So, each process will have all together different global variable 'hWindow'. To avoid this you'll have to use the concept of data sharing among the DLLs/Process. Following links may help you.
Data Sharing Among DLL/Process[^]
Hooking Sample[^]
- Malli...! ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
Even if each process has a different hWindow, wouldn't the function "HookHwnd" I created set every hWindow to the same value?
Anyway, thank you for the links, I'm going to try this 
|
|
|
|
|
Tony_P wrote: wouldn't the function "HookHwnd" I created set every hWindow to the same value
You could actually make it work this way. You use the RegisterWindowMessage Function[^] to create a unique window message and broadcast it using HWND_BROADCAST[^]. Just make sure that your window message is unique and its not in the WM_USER range so it will not conflict with custom window messages used internally in other applications. RegisterWindowMessage will return something in the range of MAXINTATOM-MAXWORD so you should be safe.
In your DLL you could handle this custom message and set the local variable to a target window handle. And since you have both WPARAM and LPARAM this means you could target both PID and window handle. Essentially instructing the DLL "Process with PID x please monitor window n".
This is a sort of hackish way of doing it in my opinion, the shared-data segment in my earlier post would probably be a better choice. You could instruct each DLL there also using a similar technique. The great thing about engineering software is there is always many paths to reach the goal.
Best Wishes,
-David Delaune
|
|
|
|
|
Wow! Thank you for sharing all this valuable information to me. Now back on Visual C++ :p
|
|
|
|
|
Tony_P wrote: Am I doing something wrong here?
Yes. Think of it this way... your DLL is being mapped into multiple applications each of which is executing inside its own Virtual Address Space[^]. This essentially means that each copy of the DLL has a different value for your global variable named hWindow.
You need to implement a shared data section:
How To Share Data Between Different Mappings of a DLL[^]
This will allow all applications to read from the shared data section.
Best Wishes,
-David Delaune
|
|
|
|
|
Well it seems like this shared memory is the solution. I'm going to try it. Thank you!
|
|
|
|
|
Hi,
In FAT file system I can access "System Volume Information" folder but in NTFS I can't.
How can I access it?
|
|
|
|
|
By ensuring that the user trying to access the folder has appropriate permissions.
Right-click the folder then sort out the user access permissions from the Sharing/Security context menu item. Pick the Security tab, then ensure the user belongs to one of the groups that has access, or create a new group that has access and add the user to it.
|
|
|
|
|
I want to do this programtically
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
