|
say you have a variable a in your first dialog, and you want to pass this value to the second dialog.
so, create the same variable a in the second dialog also, and do the following.
CSecondDialog s;//if CSecondDialog is your class.
s.a=a;
s.Domodal();
so here, you can access a from any function in the second dialog.
|
|
|
|
|
Maybe a little bit late  . Anyway, there is an article here[^] that describe what you are looking for.
|
|
|
|
|
If we suppose that main dialog is CMain you can use of this line on other dialogs.
CMain* m_Main=(CMain*)GetParent();
m_Main->yourvariables;
|
|
|
|
|
In which method of MFC's CMDIFrameWnd or its clientarea (a subclassed CWnd of m_hWndMDIClient) should one create a simple CControlBar ?
I've tried it blindly (which is BAD practice I know):
BOOL ApplicationFrame::OnCreateClient(LPCREATESTRUCT lpCs,CCreateContext *pContext) {<br />
BOOL r;<br />
r = CreateClient(lpCs,NULL);<br />
if(r) {<br />
m_pToolbar = new Toolbar();<br />
ASSERT(m_pToolbar);<br />
ASSERT(this);<br />
m_pToolbar->SetBarStyle(CBRS_ALIGN_TOP);<br />
m_pToolbar->SetInPlaceOwner(this);<br />
}<br />
return r;<br />
}
Where:
class ApplicationFrame : public CMDIFrameWnd {<br />
}
but the control bar is not showing up (I can't see it even with spy++). What am I missing and how to do it right ?
|
|
|
|
|
As with all MFC windows, control bars are created in two steps - one for
the C++ object and one for the Windows object (HWND).
You are missing the second part - you need to call Create() or CreateEx()
on your m_pToolbar object.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Hi,
I have some CListCtrl - and after i insert all my item into it i want to choose the first item.
How can i do it ?
Thanks for any help.
|
|
|
|
|
CListCtrl list_control;
list_control.<a href="http://msdn2.microsoft.com/en-us/library/9t97k8h9(VS.80).aspx">SetItemState</a>(0,LVIS_SELECTED,LVIS_SELECTED);
Software Zen: delete this;
|
|
|
|
|
We are having problems with FindFirstChangeNotification using vista - I wonder if anyone can help or has had similar problems.
We have been using FindFirstChangeNotification to monitor images coming in from a camera for a couple of years now (on XP) with no problems. We have now got a couple of laptops running Vista and find we only get notifications on every other image coming in (we then pick up both new images).
However if we run Windows Explorer at the same tim and view the folder the images are coming into with it then we get each notification as each mage comes in.
Minimise the Windows explorer and we are back to getting notifications every other image!
On top of that we are printing stuff every thrid image and if we turn the printing off we get notifications on every image (whether or not Explorer is running).
The only relationship I can see with all this is it seems to be some sort of client server issues.
If anyone can help it would be much appreciated!! Thoug I suspect it may be a case of waiting until the first (or second service pack) comes out.
|
|
|
|
|
Is this of any help? Also, does the folder you're watching contain any symbolic links?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I'm not sure - it might do and I'll give it a whirl in a couple of days time. However it is not running across a network but on the other hand I guess there are pretty much always going to be other processes that have a notification on if you happen to have a Windows Explorer open on that folder. Unfortunately when we have an explorer open to that folder is exactly when it seems to work correctly - ho hum!!!!
There are no symbolic links set up at all - very simple folder set up indeed.
As I say I'll probably get a chance to have a try in a coupld days.
Thanks.
Mike
|
|
|
|
|
OK I've had more time to work on this and though I haven't got anything conclusive, I think the problem was at my end (it usually is!). We discovered the problem only occurred with files copied in by Canon cameras, other cameras had no problems - leading me to suspect a timing problem.
After some digging I determeined that there was a function call doing considerable work between receiving the response from WaitForSingleObject and the following call to FindNextChangeNotification. I now make that call almost immediately and the problem now seems to be sorted (fingers crossed). The problem is that Canon copy a small temporary file before copying the main image file and I suspect the main image file was coming in before the call to FindNextChangeNotification and so it was being missed.
Thanks again for your help.
|
|
|
|
|
is a driver (sys file) a com program?
Zo.Naderi-Iran
|
|
|
|
|
No[^].
Software Zen: delete this;
|
|
|
|
|
I'm not a C++ guy, but I've been reading today about how multiple inheritance isn't supported in C#. Most commentators (say Jesse Liberty) say something like "I never needed to use multiple inheritance" etc.
It left me curious to know what problems folks have solved using multiple inheritance?
Me: Can you see the "up" arrow?
User:Errr...ummm....no.
Me: Can you see an arrow that points upwards?
User: Oh yes, I see it now!
-Excerpt from a support call taken by me, 08/31/2007
|
|
|
|
|
martin_hughes wrote: Most commentators (say Jesse Liberty) say something like "I never needed to use multiple inheritance" etc.
I've never had to do it either.
martin_hughes wrote: It left me curious to know what problems folks have solved using multiple inheritance?
Most classes do not require more than one "is a" relationship. With MFC, the problem that occurs is when the derived class has two CObject-related classes as parents. The framework does not know which is the "real" (cause only one of them can be) parent.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Multiple inheritence is typical in COM objects when the objects implement multiple interfaces.
I also use it in a utility library. For example, I've got dialog and property page classes that derive from CDialog and CPropertyPage, respectively, along with a layout manager class that is shared between them.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: For example, I've got dialog and property page classes that derive from CDialog and CPropertyPage...
Why?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Our UI's are touch-screen driven. The derived classes provide services specific to that environment, along with enhancements that the base classes don't provide. Touch-screen services include automatic subclassing for certain types of controls (such as on-screen popups for edit controls), layout handling, and so on. The enhancements include a modest 'skinning' facility.
In case your 'why?' was directed at our use of MFC, that's simple. When we started the series of products that came from this code base, it was 1999. .NET wasn't available. At this point we have a mature and robust toolset that meets our needs.
We'll look at VS2008, especially when we start thinking about targeting Vista and its associated eye-candy.
Software Zen: delete this;
|
|
|
|
|
I was just curious since CPropertyPage is already derived from CDialog. Was there are point in time that this was not so?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
DavidCrow wrote: CPropertyPage is already derived from CDialog.
AFAIK, that's been the case at least since VC6/MFC4.2.
I had to create classes derived from both, since I wanted to make services transparently available to both dialog and property page handlers. There isn't a simple way to inject your code into the inheritance chain between CPropertyPage and CDialog. For that reason, I've got this:
class GalaxyUI_Dialog: public CDialog, GalaxyUI_Form {
};
class GalaxyUI_PropertyPage: public CPropertyPage, GalaxyUI_Form {
};where the GalaxyUI_Form class has the common elements.
The only thing that's a little odd-looking are the message handlers. For example:
void GalaxyUI_Dialog::OnSize(UINT nType,int cx,int cy)
{
CDialog::OnSize(nType,cx,cy);
GalaxyUI_Form::OnSize(nType,cx,cy);
}Sometimes the derived classes call their 'base' class only, the form class only, or both.
Software Zen: delete this;
|
|
|
|
|
See here[^].
My favorite quotation: People quite correctly say that you don't need multiple inheritance, because anything you can do with multiple inheritance you can also do with single inheritance. You just use the delegation trick I mentioned. Furthermore, you don't need any inheritance at all, because anything you do with single inheritance you can also do without inheritance by forwarding through a class. Actually, you don't need any classes either, because you can do it all with pointers and data structures. But why would you want to do that? When is it convenient to use the language facilities? When would you prefer a workaround? I've seen cases where multiple inheritance is useful, and I've even seen cases where quite complicated multiple inheritance is useful. Generally, I prefer to use the facilities offered by the language to doing workarounds.
|
|
|
|
|
I've worked on projects that make use of multiple inheritance, and, like any tool, it can be or a good and a bad thing depending on the context. Probably the most common usage in C++ is in implementing interfaces: in C++ you need to use multiple inheritances to implement multiple interfaces or even to implement one if you’re also deriving from another class in addition to implementing the interface. In C# you don’t use multiple inheritance to implement interfaces so this is not an issue. Another common use of multiple inheritance is to use mixins[^].
Steve
|
|
|
|
|
MI is nice for implementing functionality where the the "is a" or "has a" relationship doesn't really exist, it's more like "I can do this and this is how I do it" type relationship.
I've used it quite a bit in programming custom controls, to let objects describe various aspects of themselves, like how they paint themselves, resize, move, etc. There's a lot of internal handshaking, but MI is a very powerful tool in this respect.
- S
50 cups of coffee and you know it's on!
|
|
|
|
|
Steve Echols wrote: MI is nice for implementing functionality where the the "is a" or "has a" relationship doesn't really exist, it's more like "I can do this and this is how I do it" type relationship.
A nice description. These are called mixins but the way you've explained it is more useful than name-dropping.
Steve
|
|
|
|
|
What you dewscribe here ist exactly how I have always used Multiple Inheritance (only seldom) apart from inheriting pure abstract interfaces.
It is about the same thing Stephen Hewitt mentions as 'mixins'. MI is how it is done in C++ and just because Java (and Microsofts second implementation of it, C#) give it a different name, it is not wrong.
I don't understand the wailing of the Java-Fanboys about C++ using this feature.
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
