|
Maximilien wrote: why don't you just pass the parent pointer to the ChildDlg when it's created and check the GetParent against that pointer ?
I think that, stated the way above, you're check will always return true.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
You can make the three candidate parents to implement the same interface (pure abstract class) that defines a method returning some type info. For instance, Suppose you define IMyTypeInfo:
class IMyTypeInfo
{
public:
virtual int getType()=0;
}
then you can do something similar to:
class Dlg1 : public CDialog, public IMyTypeInfo
{
public:
virtual int getType(){return 1;}
...
}
class Dlg2 : public CDialog, public IMyTypeInfo
{
public:
virtual int getType(){return 2;}
...
}
class Dlg3 : public CDialog, public IMyTypeInfo
{
public:
virtual int getType(){return 3;}
...
}
finally, you child dialog, can safely do the following cast:
int iType = ((IMyTypeInfo *)GetParent())->getType();
and retrieve parent's type.
(you can also go through RTTI...)
hope that helps.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Be careful if these dialogs are modeless. What GetParent() and GetWindow() report differs depending on the dialog style (i.e. popup, overlapped, or child)
Be aware of the differences of parent and owner depending on these styles.
Window Owners and Parents
[^]
|
|
|
|
|
This example is MFC
In each parent, create the child like:
CChildDlg childDlg (this)
This will pass the parent CWnd to the child and the standard MFC implementation will store the CWnd pointer.
In the child, when something occurs that has to be sent back to the parent, simply do:
GetParent ()->PostMessage (build whatever message and parameters you need)
If the child really cares about _which_ parent called him, modify the child's constructor to include another parameter and pass in an indicator that the child can store in its member variables that shows who created the child.
CChildDlg childDlg (this, flag_value)
Now, in the child, when you want to call into a specific parent, cast the parent CWnd pointer to the appropriate parent class based on the flag
if (flag_value == parent_1)<br />
{<br />
Dlg1 *pDlg = (Dlg1 *) GetParent ();<br />
}<br />
else if (flag_value == parent_2)<br />
{<br />
Dlg2 *pDlg = (Dlg2 *) GetParent ();<br />
}<br />
else<br />
You need to be careful when you call back into another window class that you don't do things that may cause your window to redraw. In general, it is much better to post a windows message than it is to call directly when communicating between windows.
Judy
|
|
|
|
|
Thanks to all who spent time for answers.
|
|
|
|
|
i am not able to get hard disk serial number in vista. i want code that can be used in vc++ 6.0 and should be able to run in vista.
i don't want to use wmi or .net framwork and without administrator login as my software can run form win95,98,me to vista. my software is not useing any api of .net.
viral joshi
|
|
|
|
|
viral_umang@hotmail.com wrote: i don't want to use wmi
Unfortunately, WMI is the easiest way to go when it comes to getting hardware information. There is a WMI redistributable for Win95, Win98, and WinNT that you can package up in an msi along with your app. The read-only side of WMI works great when logged on as a regular user (non-admin). I program with it in Visual C++ 6.0 (Platform SDK is required on your Visual C++ 6.0 machine) and it works fine on Vista.
Now, I agree with you on the "no dotNet stuff" and WMI is quite complex since it is DCOM based but it hasn't weighed me down too much since the queries are always on the same box. DCOM seems heavy only when you try to do stuff remotely. There are just too many variables involved with trying to write your own code for every possible piece of hardware out there that may be underneath any Win95-Vista installation for even the most conservative programmer.
If you've never programmed in COM or DCOM, then I might understand any hesitation or reluctance since the initial learning curve is substantial in Visual C++ but if your a veteran COM programmer, this is one of those rare instances where I'd have to ask "Why not give it a try?". Once you write the code for one property, you can reuse that code for most others.
|
|
|
|
|
hi
thanks for the reply
my code is working fine upto winxp. but i am not able to get same info in vista. it return blank. i am able find out wich os is runing and base on i can call that function. that is ok. just i want what are the change in vista to get hdd serial number.
if i include wmi with my app. deploment set get big as it include complet wmi and i want only one info i.e. hdd serial no. so it would be not good just to include whole stuff in my deploment setup. this is same case with dotnet framework. that is why i want to write this code i my app.
thank you
|
|
|
|
|
Fair enough.
What method are you using to obtain HDD Serial number as it might help understand what might be stopping it?
Just to see if it's related to UAC, have you disabled UAC temporarily while trying your code to see if it works. I'm not sure how that could affect code that normally runs as "user" but Vista has been throwing some pretty mean curveballs my way the last few weeks so it might not be a bad idea to try that.
If you go to administrative tools, Local Security Policy, Local Policies, Security Options, and scroll to the "User Account Control:" settings and disable them (Just for testing) and try what you are trying and it works, then you found the culprit(s). You may need to logoff/logon or restart to get the new settings to apply.
|
|
|
|
|
Greetings All,
I have a client CSocket sending information to a server CSocket. For simplicity, I make the client scocket send message only, without receiving or processing any returned message.
I wonder, if the server keeps sending back acknowledgements and piles up the client's receiving buffer, what will happen. Will old messages be automaticly cleared? Or, will click socket crash due to the buffer overflow?
Is there any way to make the client socket automatically discard all returned message and clear the receiving buffer?
Many thanks,
Bill
|
|
|
|
|
TCP protocol?
Is the server sending acknowledgements or are you talking about the ones that are part of the
protocol?
If you are sending bytes then they should be flushed (recv'd) at the destination but the protocol
ACKs will be stripped by the protocol stack.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Thanks for the reply.
I was talking about the message sent back by the server. The server intendedly sends back some information via the connected socket, but the client doesn't need it. Therefore, I didn't use OnReceive() in the client side. And, I do not know how to make the client automatically delete those messages from the stack.
I was just curious if this would overflow the buffer of the client port.
Thanks.
Bill
|
|
|
|
|
Yes the buffer will fill up on the receiving side. That will cause the sending side not to send
which means the send buffer will fill there as well. On the send side, a blocking socket will
block indefinitely and a non-blocking socket will indicate an WSAEWOULDBLOCK error on subsequent
sends.
If reply/acknowledge data is sent by the server in your communication protocol then it's
probably best to recv it at the client even if you do nothing with it.
I suppose it will work with the buffers full if both ends handle the condition correctly but if
efficiency is important it's best to keep the buffers flushed.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Yes, I am talking about TCP socket.
|
|
|
|
|
how to access group policy through wmi using mfc. i have to add script to be run at shutdown time. how to query this to group policy in wmi
Arise Awake Stop Not Till ur Goal is Reached.
|
|
|
|
|
We have recently been tasked with modifying all of our .cpp, .h, and .c files to include a specialized header at the top of the files.
Is anyone familiar with any application that apply this header programmatically and save us a lot of manual work?
|
|
|
|
|
I don't know of any.
But it shouldn't take more than a couple of hours to write one of your own.
I would make a dialog based app that would let me select a file that contained the header I wanted and then let me browse for a folder where my source files were located.
Making it more fancy, e.g. a tree view with checkboxes for all files, would probably take two more hours to make it work properly.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Maybe you can include it in your stdafx file if you use one ?
|
|
|
|
|
I have done this with a macro in the past - both in VC6 and in VS2005. It means you have to open each file in the editor and select the macro, but that's better then hand-typing the header every time.
Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
|
|
|
|
|
After some digging, I did decide to write my own application in C# that will take a header file and apply it to the top of every source code file.
|
|
|
|
|
You could do that in a few lines of Perl
|
|
|
|
|
Dear All;
I have noticed that once I close a dialog box from the (x) icon -top most right corner-, the dialog is not destroyed. By the way, this dialog is a child of a another main window.
How do i destroy a child window only whenever the user tries to close it from x icon?
Is it enough to add OnClose() event handler to the dialog box? and what should it contain? I have tried the code below but this resulted in the closure of the whole application which i dont want:
<br />
void ChildDlg::OnClose()<br />
{<br />
PostQuitMessage(WM_QUIT);<br />
CDialog::OnClose();<br />
}<br />
Thank you
-- modified at 10:40 Friday 13th April, 2007
llp00na
|
|
|
|
|
Is this a modal or modeless dialog box? Modeless dialogs require some additional thought and consideration.
|
|
|
|
|
I am using a modeless dialog box. Would you also please explain how does it differ when using modal dialog? Thank you
llp00na
|
|
|
|
|
A modal dialog is invoked with DoModal() and it does not return until the dialog is dismissed effectively preventing interaction with the owner.
A modeless is created with Create() and returns immediately leaving the owner AND the dialog open for interaction.
Referencing Jeff Prosise's book I get...
Modeless:
1) Dismiss the dialog using DestroyWindow and not EndDialog()
2) Do not allow CDialog::OnOK or CDialog::OnCancel because both call EndDialog()
3) Instantiated with "new"
4) Override CDialog::PostNCDestroy in the derived dialog class and execute "delete this"
Modal:
1) Dismiss the dialog with EndDialog(). Refer to Mr. Sivakumar's views on modality[^] for additonal info
2) Instantiated on the stack
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
