|
Hi,
I've done the modeless dialog thing once and what I can remember was that you had to recreate the thing, I just can't remember how I did it, but I've found it in literature then, so I'll bet you can find it too.
Search for some sample code on the net or in some MFC book or something.
Sorry I can't remember more than this, it's been a long time.
Good luck.
"If I don't see you in this world, I'll see you in the next one... and don't be late." ~ Jimi Hendrix
|
|
|
|
|
|
If an Abstract Base Class is never going to be instantiated, why do some have ctors in them (ctors which have nothing to do with the ABC)?
To me, it'd be clearer to see those activities occurring in the derived class(es).
William
Fortes in fide et opere!
|
|
|
|
|
I think when we derive a class from it, and instantiate it, the object will access on the constructor.
<italic>Work hard and a bit of luck is the key to success. You don`t need to be genius, to be rich.
|
|
|
|
|
I think the derived class needs to know what constructor to use? Or something. 
[EDIT]
to clarify: you can have multiple contstructors with a different parameter set. The derived class needs to know what constructor to override.
[/EDIT]
"If I don't see you in this world, I'll see you in the next one... and don't be late." ~ Jimi Hendrix
|
|
|
|
|
Strange question. Every class has it's own constructor whether it is an ABC or not. In the case of ABCs, the derived classes must allow the user to supply the arguments for the base. When you instantiate an ABC through a derived class, the derived class constructor is called first and that constructor will will invoke the base class constructor. So let's say the base class requires a variable to be initialized. The derived class may not care about that variable (may not use it) but the derived class must provide the means in it's own constructor to get the input data and pass it along as an input argument to the base class constructor.
I don't really understand the context of your question so there is no way for me to know if anything I've said is applicable to what you are really asking. I just felt like typing I guess; I'm intrigued by the question. If you get a minute, please provide an example or examples of what you are talking about.
|
|
|
|
|
Thanks for replying.
If my C++ understanding serves me well, when an object is instantiated, the compiler allocates the amount of space the object will need according to its type. The class CTOR is called upon as part of that Allocation-Instantiation process to initialize data members, (etc.).
Since an ABC is never going to be instantiated, it always confuses me why would there be a CTOR (or several CTOR's) for an ABC. It's never going to become an object, and so, no memory will be allocated for it!! Therefore, why even define it with data members?? (That's one of the things about C++ that I've never quite understood. An ABC is NOT a concrete class. It'll never become an object, and no memory will be allocated for it, yet it has a CTOR, and member variables defined in it. Strange!!)
Then I look at some ABC that have CTORs (plural), and I can see what they are doing. They're fulfilling the role of the ABC as an interface for the derived class(es). OK! I see that.
The water starts getting a little muddier when the explanation offered for multiple CTOR's as (sort of) being there to customize the interface for the respective derived classes for which the ABC is acting as base class.
To me, it sounds like something which started out clean and clear, then little by little, starts taking on multiple roles to the point where one has to ask, "Isn't this the same class that originally couldn't be instantiated?"
The interface part I can understand, but when that interface role starts becoming a sort of "do all for all", that's when I find it useful to step back and say, "Now wait a minute, are we talking about an ABC here, or what?"
William
Fortes in fide et opere!
|
|
|
|
|
Virtuality is a complex subject for those beginning with C++ but after you have developed for a few years it makes sense.
Firt, let me try to give you another perspective. When you say the ABC will never become an object, you are not entirely correct. It can never become an object by itself. When a derived class is instantiated, the base class is also instantiated. You have two completely separate objects being instantiated and therefore two constructors. On a UML object diagram, you'd show an object for the system. But really there are multiple classes within the object that can be pointed to separately. Check out this example.
Let's say you have two classes, ABC_Base and derived.
within some function, I want to instantiate the class:
ABC_Base* theObjPointer = new derived(UINT nRadius, float pi);
Now you have a pointer to the base class. The only way to call a function in the derived class is through virtual functions. In order to call a function that is only in the derived class you would have to downcast the pointer into a pointer of type derived*. You see, a pointer to this new object could be a pointer to either object. So it's not one object that you have instantiated.
Let's say you did this instead:
derived* theDerivedObjPtr = new derived(int nRadius, float pi);
Now you have a pointer to the same kind of object. But now it is a type that points to the derived class.
You could dynamically cast this pointer value into the other variable as well. Look up dynamic_cast in one of your C++ books.
In order for this to work, there must be two distinct addresses, one for each class within the object. Of course the compiler somehow builds virtual tables so that the virtual functions are linked. By the way, the constructors are never virtual. The derived class constructor is always called first and subsequently calls the constructor in the class that it inherits directly from; and on up the chain. Now the destructor should be virtual since there are different pointer types. So if you want to delete the object using the theObjPointer variable, your destructors better be virtual, otherwise you'll only really destruct the base class part of the object and not the derived class part of the object. Another example to help reinforce that you really have muliple things within the object you've constructed.
Felt like rambling for a while; so I hope I gave you another perspective you hadn't thought of.
Regards,
Shawn
|
|
|
|
|
Thanks for replying again.
My confusion with an ABC is NOT about the position it occupies in the hierarchy structure (meaning, that its ctor is going to be invoked and executed first, ahead of its derived classes). My confusion (and to some extent, 'frustration') is with the evolving role it is called upon to fulfill.
ABC's are promoted first and foremost as class(es) which cannot be instatntiated because it contains a 'pure virtual function', and therefore can ONLY be used as an interface for the hierarchy structure to which it is the base class.
Well, hold on! Don't base classes on a whole perform the same kind of role to the hierarchy structure they, too, are a part of? Base classes contain member variables, and functions that are common to what their derived class(es) will (or might) use. Such kinds of base class also use virtual functions, and act as interface to their derived class(es).
The ONLY difference I see between a regular base class and an ABC, is that you are FORCED to override the 'pure virtual functions' in an ABC, whereas in non-ABC classes, you ONLY override those base class functions if you want the derived ones to be more specific than what the base functions provide. That's it.
The notion of when which class gets instantiated first, or before which other ones, isn't salient.
Then I turn to the next factor which is the multiple CTORs ABC's are sometimes given to bear (in the name of flexibility for its role as 'interface'). Because of the order in which base class(es) are instantiated, I understand data from derived class(es) needs to be passed up the chain in order for the base class(es) to be properly initialized. This fact (sadly) contributes to my whole point of UNNECESSARILY burdening a class which originally started out to be an ABC, simply because its main role was to be an interface, suddenly starts turning out to be a "do all for all" type interface. I just feel the picture would be a lot clearer if some of those gratuitous roles could be reversed and bourned by its own derived class(es).
Lastly, since the time of posting my question and now, I've done quite a bit of reading on ABC and have discovered several "behind the scene" activities the compiler does that are not readily revealed in 99.99% of C++ books. The most important being that it is ONLY a syntactical requirement that ABC's NOT be instantiated by the programmer, while in truth an fact, it DOES get instantiated by the compiler and is treated (by the compiler in its own unique way) as any base class object. The overwhelming difference in identity lies with the way the programmer needs to treat and handle ABC (two different set of rules: one for the programmer, and one reserved for the compiler).
Perhaps, at some time in the future (when time permits), I'll look at the underlying Assembly code to see what those differences are, but for right now, I'll just know that syntactically there are certain things I cannot do with and ABC, whereas the compiler makes amends for whatever it does "behind the scene".
Thanks again for replying.
William
Fortes in fide et opere!
|
|
|
|
|
I have a VC++6 application that has two edit fields (m_edit1, m_edit2)and a button. When the application starts, m_edit1 displays the following text:
lastname;firstname;gender;phoneNumber;email
I want to read the third field "gender" and display it in m_edit2 when the button is pressed.
Any help will be greatly appreciated
|
|
|
|
|
use CString a;
a.Find and parse it
<italic>Work hard and a bit of luck is the key to success. You don`t need to be genius, to be rich.
|
|
|
|
|
Use AfxExtractSubstring() for this.
CString strText, strGender;<br />
m_edit1.GetWindowText(strText);<br />
AfxExtractSubstring(strGender, strText, 2, ';');
"Opinions are neither right nor wrong. I cannot change your opinion of me. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
is it possible to initialize the browser dialog with a specified directory when call SHBrowseForFolder?
I mean:
when the browser dialog displays, it selects a directory as Initial Directory.
in OPENFILENAME, we can set lpstrInitialDir then call GetOpenFileName.
includeh10
|
|
|
|
|
In the BROWSEINFO structure, set the lpfn member to a callback function. In that callback, send a BFFM_SETSELECTION message back to the SHBrowseForFolder dialog, passing the path in the LPARAM parameter.
See http://www.codeproject.com/editctrl/fileeditctrl.asp[^] for an example of code that does this.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" mYkel - 21 Jun '04
Within you lies the power for good - Use it!
|
|
|
|
|
Hi. im kinda used to the "I write the methods and classes, call them from the main()" way of programming but now in MFC I cant find a way of doing this. Does mfc still work that way???
|
|
|
|
|
It's not just MFC, it's Windows that doesn't work that way.
Windows is an event-driven operating system and needs a completely different approach to programming. Learn what that involves first and then decide whether or not to use MFC to do it.
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
|
|
|
|
|
What you describe is the difference between synchronous and asynchronous programs. DOS and text-based programs are based on the former, while Windows is based on the latter.
"Opinions are neither right nor wrong. I cannot change your opinion of me. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
From a layman's prepective MFC and Windows apps have InitInstance() and WinMain() as a parallel to "main() programmers"
Dharani Babu S
|
|
|
|
|
What in the world are you talking about? Not all MFC applications have an InitInstance() method. While a GUI-based Windows application has a WinMain() function, a text-based Windows application has a main() function.
"Opinions are neither right nor wrong. I cannot change your opinion of me. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
Hi all i wanna how to create tab control
i wanna create
(1)dialog tab
(2)form view tab
|
|
|
|
|
I want to use the follow codes to capture screen ,but I get a black screen.
Please help me to find the errors!
thanks!
HWND hDesktopWnd=::GetDesktopWindow();
HDC hDesktopDC=::GetDC(hDesktopWnd);
HDC hDesktopCompatibleDC=CreateCompatibleDC(hDesktopDC);
HBITMAP hDesktopCompatibleBitmap=CreateCompatibleBitmap(hDesktopDC,GetSystemMetrics(SM_CXSCREEN),GetSystemMetrics(SM_CYSCREEN));
SelectObject(hDesktopCompatibleDC,hDesktopCompatibleBitmap);
BitBlt(hDesktopCompatibleDC,0,0,GetSystemMetrics(SM_CXSCREEN)
,GetSystemMetrics(SM_CYSCREEN)
,hDesktopDC,0,0,SRCCOPY);
// InvalidateRect(NULL,false);
HDC hBmpFileDC=CreateCompatibleDC(hDesktopCompatibleDC);
HBITMAP hBmpFileBitmap=CreateDIBSection(hDesktopCompatibleDC,&bi,DIB_RGB_COLORS,&pBits,NULL,0);
SelectObject(hBmpFileDC,hBmpFileBitmap);
BitBlt(hBmpFileDC,0,0,width,height,hDesktopCompatibleDC,0,0,SRCCOPY);
// the fellow codes is save the bitmap
HANDLE hFile=CreateFile((unsigned short *)szFileName,GENERIC_WRITE,FILE_SHARE_WRITE,NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL);
bi.bmiHeader.biBitCount=16;
// bi.bmiHeader.biClrUsed=0;
bi.bmiHeader.biHeight=GetSystemMetrics(SM_CYSCREEN);
//GetHeight();
bi.bmiHeader.biWidth=GetSystemMetrics(SM_CXSCREEN);
//GetWidth();
bi.bmiHeader.biSize=sizeof(BITMAPINFOHEADER);
bi.bmiHeader.biPlanes=1;
bi.bmiHeader.biCompression=BI_RGB;
// bi.bmiHeader.biXPelsPerMeter=0;
// bi.bmiHeader.biYPelsPerMeter=0;
// bi.bmiHeader.biClrImportant=0;
DWORD bitSize=((bi.bmiHeader.biWidth*16)/8)*bi.bmiHeader.biHeight;
bi.bmiHeader.biSizeImage=bitSize;
bitHeader.bfType=((WORD)('M'<<8)|'B');
bitHeader.bfReserved1=0;
bitHeader.bfReserved2=0;
bitHeader.bfOffBits=(DWORD)(sizeof(BITMAPFILEHEADER)+bi.bmiHeader.biSize);
bitHeader.bfSize=bi.bmiHeader.biSizeImage+bitHeader.bfOffBits;
if(hFile!=INVALID_HANDLE_VALUE)
{
DWORD dwRet=0;
WriteFile(hFile,&bitHeader,sizeof(bitHeader),&dwRet,NULL);
WriteFile(hFile,&bi.bmiHeader,sizeof(bi.bmiHeader),&dwRet,NULL);
WriteFile(hFile,pBits,bi.bmiHeader.biSizeImage,&dwRet,NULL);
CloseHandle(hFile);
}
DeleteDC(hBmpFileDC);
DeleteDC(hDesktopCompatibleDC);
::ReleaseDC(hDesktopWnd,hDesktopDC);
DeleteObject(hBmpFileBitmap);
DeleteObject(hDesktopCompatibleBitmap);
|
|
|
|
|
Do not get the desktop window DC. It causes serious problems.
Instead of this
HWND hDesktopWnd=::GetDesktopWindow();
HDC hDesktopDC=::GetDC(hDesktopWnd); write this
HDC hDesktopDC = ::CreateDC("DISPLAY",0,0,0);
|
|
|
|
|
Hi All,
I'm facing a strange problem.
The condition is like this:
minimize the application from the taskbar when a dialog is displayed
or a automatic dialog is displayed when the application is in the minimized position.
When the user clicks to activate this minimized window,only dialog box is coming up and the application's main window still remains minimized.
This is happening sometimes.
Can some one tell me how to make the main window also to come up along with the dialog box when the window is activated from a minimized position
Thanks in advance
Raghu
|
|
|
|
|
Hello,I want to capture the screen with GDI functions ,
could you give me some samples?
my computer does not support GetDIBit()function,
Thanks
|
|
|
|
|
Try this one.
"Opinions are neither right nor wrong. I cannot change your opinion of me. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
