Re: Open dialog? - C / C++ / MFC Discussion Boards

If the window is going to be opened and closed lots of times, then it'd make sense to not close the window at all, but just hide it away

i.e.
m_modless.ShowWindow(SW_HIDE); to hide it, then m_modless.ShowWindow(SW_SHOW); to make it re-appear

(remember not to try and re-create the window when you re-show it, you only need to do that the first time you use the window)

--
Help me! I'm turning into a grapefruit!
Phoenix Paint - back from DPaint's ashes!

Thanks that work great.

Well I get the error: ASSERT(::IsWindow(m_hWnd));

On my main dialog I show the modless dialog and on the modless dialog I try to close it.

MAIN dialog
CModless m_modless;
m_modless.ShowWindows(SW_SHOW); // Works Greate

Modless dialog (on close )
CModless m_modless;
m_modless.ShowWindow(SW_HIDE); // Get the error.

On initdialog on the main dialog I use,
m_modless.Create(IDD_MODLESS); // To create the modless dialog.

It works to show the dialog but not to close it.
What Im I doing wrong?

This is because in both cases you're creating a brand new (and private to the function) instance of m_modless, so the attempt to hide the window is hiding a different (non-existing) window to the one you show'd earlier.

You need to make m_modless a member variable of your class, instead of being a variable within your show/hide functions.

--
Help me! I'm turning into a grapefruit!
Phoenix Paint - back from DPaint's ashes!

The suggestion you got earlier about hiding the dialog is ok, but in case you do want to close it in the future so that the modeless dialog is not holding onto memory that your application doesn't need to have, this is what you should do. Make a member pointer variable of the type of your calling class in your modeless dialog's class. Alter the constructor so that it has to have a pointer of the calling class's type (make sure to use a forward declaration in your header file). Like this:

class CCallingClass;  //forward declaration

class CMyModelessDialog : public CDialog
{
  CCallingClass* m_pCaller;
};

in your constructor, set the member pointer equal to the pointer sent in. Then when you want to close the dialog, do this:

m_pCaller->SendMessage(WM_USER_CLOSE_MODELESS);

In your stdafx.h file,

#define WM_USER_CLOSE_MODELESS (WM_USER + 1001)

Add a message map entry for your #defined message like any other message, and map it to the appropriate function. In that function, do this:

m_modless.DestroyWindow();

Who are all these people and what are they doing in my house?...Me in 30 years, inside a grocery store

My articles[^]
bdiamond Sleepy | :zzz:

Well I get the error: ASSERT(::IsWindow(m_hWnd));

On my main dialog I show the modless dialog and on the modless dialog I try to close it.

MAIN dialog
CModless m_modless;
m_modless.ShowWindows(SW_SHOW); // Works Greate

Modless dialog (on close )
CModless m_modless;
m_modless.ShowWindow(SW_HIDE); // Get the error.

On initdialog on the main dialog I use,
m_modless.Create(IDD_MODLESS); // To create the modless dialog.

It works to show the dialog but not to close it.
What Im I doing wrong?

Larsson wrote:
from the modless dialog I try to use
OnOK();

You most override OnOK() (and OnCancel()) in order to close a modeless dialog. Do not call the base class OnOK(), which calls EndDialog(), but call DestroyWindow() instead.

"Opinions are neither right nor wrong. I cannot change your opinion of me. I can, however, change what influences your opinion." - David Crow

Well I get the error: ASSERT(::IsWindow(m_hWnd));

On my main dialog I show the modless dialog and on the modless dialog I try to close it.

MAIN dialog
CModless m_modless;
m_modless.ShowWindows(SW_SHOW); // Works Greate

Modless dialog (on close )
CModless m_modless;
m_modless.ShowWindow(SW_HIDE); // Get the error.

On initdialog on the main dialog I use,
m_modless.Create(IDD_MODLESS); // To create the modless dialog.

It works to show the dialog but not to close it.
What Im I doing wrong?

CModless *modeless = new CModless;
// call Create(IDD) in the constructor of CModless
modeless->ShowWindow(SW_SHOW);
 
void CModless::OnOK()
{
    DestroyWindow();
}
 
void CModless::OnCancel()
{
    DestroyWindow();
}
 
void CModless::PostNcDestroy()
{
    delete this;
}

"Opinions are neither right nor wrong. I cannot change your opinion of me. I can, however, change what influences your opinion." - David Crow

Hello,
I have open a modless dialog winodws and I need to close the window. Is I do that i works but if I try to open the dialog again it fails.

So how can I open and close a modless dialog and it works?

I have a dialog and from that dialog I need to bring up a modless dialog and close so it needs to be open and close.

This is how I have done!

Main dialog.
m_modless.create(IDD_MODLESS);
m_modless.SHowWindow(SW_SHOW);

.... And the modless dialog is shown.
from the modless dialog I try to use
OnOK(); // To close the dialog and it works but I can NOT open the modless dialog again.
And I have try to use,
CModless m_mod;
m_mod.CloseWindow(); // and this do NOT work at al.

Please help me someone.

destroy it and re-create it...

You can however find more info on modeless dialogs on MSDN.

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

Should I destoy the dialog like this?
CModless m_mod;
m_Mod.DestroyWindow

Well that dont work I get this error code;

ASSERT(pWnd->m_hWnd == NULL); // only do once

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

ok

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).

Confused | :confused:

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. Smile | :)

[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?"

Unsure | :~

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.

Smile | :)

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