Simple Input In a MFC application

[s***@gmail.com]

Hi I need to input certain text value from a user. This is a MFC
application and I am not able to find a control which can do this. Do
I _have_ to write a custom Dialog box or is there something like
MessageBox which can also take user input ?

Regards
Sandeep

[Vipin [MVP]]

Place an edit control on a dialog or FormView and let the user input the
text
over there.
--
Vipin Aravind

Post by s***@gmail.com
Hi I need to input certain text value from a user. This is a MFC
application and I am not able to find a control which can do this. Do
I _have_ to write a custom Dialog box or is there something like
MessageBox which can also take user input ?
Regards
Sandeep

[Scot T Brennecke]

Although creating a dialog resource and CDialog-derived class is really easy in MFC, you could avoid
doing it if you really, really needed to. You can create a CEdit control on-the-fly as a child of
another window, and get the user to input their text to it. Perhaps if you explained why you want
to avoid creating a dialog, I could give you better advice.

Post by s***@gmail.com
Hi I need to input certain text value from a user. This is a MFC
application and I am not able to find a control which can do this. Do
I _have_ to write a custom Dialog box or is there something like
MessageBox which can also take user input ?

[KMA]

Sandeep,

There have already been a couple of suggestions, but with regard to you
roriginal request, you're right. Surprisingly there is no standard input box
available a la Visual Basic. Amazing oversight, in my opinion.

what I did was to write a simple dialog with a text box and a prompt label
and use that. If you think you might need it in more than one app then
create the dialog using a template in memory (see DynDialog eg in code
project) then you can add it to a (static) library.

Slap on the forehead for MFC designers though, a la Benny Hill.

Post by s***@gmail.com
Hi I need to input certain text value from a user. This is a MFC
application and I am not able to find a control which can do this. Do
I _have_ to write a custom Dialog box or is there something like
MessageBox which can also take user input ?
Regards
Sandeep

[Ajay Kalra]

I am not sure what you mean by no standard input box availability. I
have not used VB that much but ultimately it must wrap a Win32 control.
I suspect it must be the edit control. You can confirm it by using SPY
on a VB app which has the input box.

------
Ajay Kalra
***@yahoo.com

[KMA]

What I mean is that MFC provides a mechanism to display a quick message
(AfxMessageBox). It one line of code for a quick and dirty bit of output.

But for input they don't give anything similar. In VB you get something
like:

string s = InputBox("Enter your name")

And lo and behold, you've got a quick and dirty way to get a string from the
user. For sure, under it all is a dialog box with an edit control. But MFC
forces you to add a dialog box to your project, make a class for it, do the
DoModal thing, use DDX to get the value transferred etc.

As I pointed out, you can make your own relatively simply, but I can't
understand why it isn't there already. I guess the reason is that anybody
whose worked with MFC for more than a few weeks has already written their
own alternative solution.

Another glaring omission is being able to load a bitmap directly from a
file. Load from embedded resource, sure, via either resource name or number.
But from an external file? Nah, write your own code. Like MFC designers
think I really want to bloat my exe with pictures.

Post by Ajay Kalra
I am not sure what you mean by no standard input box availability. I
have not used VB that much but ultimately it must wrap a Win32 control.
I suspect it must be the edit control. You can confirm it by using SPY
on a VB app which has the input box.
------
Ajay Kalra

[Tom Serface]

I think that the MFC designers thought that people would want a more elegant
solution for entering data. To be fair the message box thing is built on
the Win32 API version so it was a natural extension. And... it is very
simple to build a data entry dialog so ... I've been on these boards for a
long time and I've seldom seen this question come up. Most MFC programmers
would like their own look and feel anyway. To be fair I seldom use Message
Box either because I want my LAF enforced throughout my program.

Tom

Post by KMA
What I mean is that MFC provides a mechanism to display a quick message
(AfxMessageBox). It one line of code for a quick and dirty bit of output.
But for input they don't give anything similar. In VB you get something
string s = InputBox("Enter your name")
And lo and behold, you've got a quick and dirty way to get a string from
the user. For sure, under it all is a dialog box with an edit control. But
MFC forces you to add a dialog box to your project, make a class for it,
do the DoModal thing, use DDX to get the value transferred etc.
As I pointed out, you can make your own relatively simply, but I can't
understand why it isn't there already. I guess the reason is that anybody
whose worked with MFC for more than a few weeks has already written their
own alternative solution.
Another glaring omission is being able to load a bitmap directly from a
file. Load from embedded resource, sure, via either resource name or
number. But from an external file? Nah, write your own code. Like MFC
designers think I really want to bloat my exe with pictures.

Post by Ajay Kalra
I am not sure what you mean by no standard input box availability. I
have not used VB that much but ultimately it must wrap a Win32 control.
I suspect it must be the edit control. You can confirm it by using SPY
on a VB app which has the input box.
------
Ajay Kalra

[Vipin [MVP]]

I think this question comes to a novice windows programmer.
It takes no time to create a dialog box with a edit control to serve as
input.
MFC does everything, Just have to click, rightclick and type in one line for
DoModal(...) and then access the member of the subclassed dialog.
--
Vipin Aravind

Post by Tom Serface
I think that the MFC designers thought that people would want a more
elegant solution for entering data. To be fair the message box thing is
built on the Win32 API version so it was a natural extension. And... it is
very simple to build a data entry dialog so ... I've been on these boards
for a long time and I've seldom seen this question come up. Most MFC
programmers would like their own look and feel anyway. To be fair I seldom
use Message Box either because I want my LAF enforced throughout my
program.
Tom

Post by KMA
What I mean is that MFC provides a mechanism to display a quick message
(AfxMessageBox). It one line of code for a quick and dirty bit of output.
But for input they don't give anything similar. In VB you get something
string s = InputBox("Enter your name")
And lo and behold, you've got a quick and dirty way to get a string from
the user. For sure, under it all is a dialog box with an edit control.
But MFC forces you to add a dialog box to your project, make a class for
it, do the DoModal thing, use DDX to get the value transferred etc.
As I pointed out, you can make your own relatively simply, but I can't
understand why it isn't there already. I guess the reason is that anybody
whose worked with MFC for more than a few weeks has already written
their own alternative solution.
Another glaring omission is being able to load a bitmap directly from a
file. Load from embedded resource, sure, via either resource name or
number. But from an external file? Nah, write your own code. Like MFC
designers think I really want to bloat my exe with pictures.

Post by Ajay Kalra
I am not sure what you mean by no standard input box availability. I
have not used VB that much but ultimately it must wrap a Win32 control.
I suspect it must be the edit control. You can confirm it by using SPY
on a VB app which has the input box.
------
Ajay Kalra

[Tom Serface]

I think it's more of a problem where Microsoft has different tools for
differnet paradigms (perhaps something .NET is trying to address). I've
seen some pretty saavy VB programmers and they probably just got used to a
"routine" that wasn't in MFC. As you say, it's easy to recreate, but one of
the things we all do when we go into new water is look for the familiar
stones :o)

Tom

Post by Vipin [MVP]
I think this question comes to a novice windows programmer.
It takes no time to create a dialog box with a edit control to serve as
input.
MFC does everything, Just have to click, rightclick and type in one line for
DoModal(...) and then access the member of the subclassed dialog.

[KMA]

I agree it doesn't take *much* time. But certainly more time than the VB
example I gave. If it really was as trivial as you imply then nobody would
use AfxMessageBox either. They'd just create their own message displaying
dialog box. But I'll bet you a pound to a penny that if you search the code
base on, say, CodeProject, you won't find many sample projects who
religeously shun AfxMessageBox for simple output. Likewise, if simple and
handy input were available many people, not just novice programmers, would
use it.

Post by Vipin [MVP]
I think this question comes to a novice windows programmer.
It takes no time to create a dialog box with a edit control to serve as
input.
MFC does everything, Just have to click, rightclick and type in one line for
DoModal(...) and then access the member of the subclassed dialog.
--
Vipin Aravind

Post by Tom Serface
I think that the MFC designers thought that people would want a more
elegant solution for entering data. To be fair the message box thing is
built on the Win32 API version so it was a natural extension. And... it
is very simple to build a data entry dialog so ... I've been on these
boards for a long time and I've seldom seen this question come up. Most
MFC programmers would like their own look and feel anyway. To be fair I
seldom use Message Box either because I want my LAF enforced throughout my
program.
Tom

Post by KMA
What I mean is that MFC provides a mechanism to display a quick message
(AfxMessageBox). It one line of code for a quick and dirty bit of output.
But for input they don't give anything similar. In VB you get something
string s = InputBox("Enter your name")
And lo and behold, you've got a quick and dirty way to get a string from
the user. For sure, under it all is a dialog box with an edit control.
But MFC forces you to add a dialog box to your project, make a class for
it, do the DoModal thing, use DDX to get the value transferred etc.
As I pointed out, you can make your own relatively simply, but I can't
understand why it isn't there already. I guess the reason is that
anybody whose worked with MFC for more than a few weeks has already
written their own alternative solution.
Another glaring omission is being able to load a bitmap directly from a
file. Load from embedded resource, sure, via either resource name or
number. But from an external file? Nah, write your own code. Like MFC
designers think I really want to bloat my exe with pictures.

Post by Ajay Kalra
I am not sure what you mean by no standard input box availability. I
have not used VB that much but ultimately it must wrap a Win32 control.
I suspect it must be the edit control. You can confirm it by using SPY
on a VB app which has the input box.
------
Ajay Kalra

[s***@gmail.com]

Post by KMA
Sandeep,
There have already been a couple of suggestions, but with regard to you
roriginal request, you're right. Surprisingly there is no standard input box
available a la Visual Basic. Amazing oversight, in my opinion.
what I did was to write a simple dialog with a text box and a prompt label
and use that. If you think you might need it in more than one app then
create the dialog using a template in memory (see DynDialog eg in code
project) then you can add it to a (static) library.
Slap on the forehead for MFC designers though, a la Benny Hill.

You've hit the nail on the point I was trying to make. I tried
searching hard for something similar to what VB provides for User
Input.
I have no specific reason not to write an Input Dialog. Just that my
application is using a HTML Control provided in MFC and there is no
external MFC component. Hence I was not keen on adding something to my
solution which would have not fitted in the current architecture. It
would have been very easy for me if something as "basic" as an Input
Box was there.

[Tom Serface]

http://www.codeproject.com/dialog/inputbox.asp
http://www.codeproject.com/dialog/muneebinputbox.asp

Tom

Post by s***@gmail.com
Hi I need to input certain text value from a user. This is a MFC
application and I am not able to find a control which can do this. Do
I _have_ to write a custom Dialog box or is there something like
MessageBox which can also take user input ?
Regards
Sandeep

[Joseph M. Newcomer]

You have not said much about what you expect here. It sounds like you are willing to have
a dialog pop up and get the input. It should take you under three minutes to create this.

(1) Create a dialog
(2) Place an edit control on the dialog
(3) Resize the dialog to minimum size (this may involve rearranging the buttons)
(4) Create a dialog class for it, for example, CMyInputDialog
(5) In the dialog class, create a value member variable, a CString, coupled to the edit
control. For example, call it m_Input.
(6) Write the following code:
CMyInputDialog dlg;
if(dlg.DoModal() == IDOK)
... use dlg.m_Input;

Done.
joe

Post by s***@gmail.com
Hi I need to input certain text value from a user. This is a MFC
application and I am not able to find a control which can do this. Do
I _have_ to write a custom Dialog box or is there something like
MessageBox which can also take user input ?
Regards
Sandeep

Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

[KMA]

OK, and now I want to use the same dialog in another project. Go through
same procedure again, making sure I drop the controls in exactly the same
place for consistancy?. Copy and paste from the resource file?

Or put it in a library? A separate dll for one dialog box? And if I want the
class statically bound?

And you really think the above take less than three minutes? I doubt it, but
anyways, it take longer than it does to write:

CString s = InputBox("Please enter your name");

Of course, you can write the function yourself. It's just a pity the MFC
group didn't take a peek at what the VB group were doing and incorporate
this very useful idea.

Post by Joseph M. Newcomer
You have not said much about what you expect here. It sounds like you are willing to have
a dialog pop up and get the input. It should take you under three minutes to create this.
(1) Create a dialog
(2) Place an edit control on the dialog
(3) Resize the dialog to minimum size (this may involve rearranging the buttons)
(4) Create a dialog class for it, for example, CMyInputDialog
(5) In the dialog class, create a value member variable, a CString, coupled to the edit
control. For example, call it m_Input.
CMyInputDialog dlg;
if(dlg.DoModal() == IDOK)
... use dlg.m_Input;
Done.
joe

Post by s***@gmail.com
Hi I need to input certain text value from a user. This is a MFC
application and I am not able to find a control which can do this. Do
I _have_ to write a custom Dialog box or is there something like
MessageBox which can also take user input ?
Regards
Sandeep

Joseph M. Newcomer [MVP]
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

[Ajay Kalra]

There are several fundamental differences between VB and MFC. VB was
catered to the developers without any significant experience. There is
a reason for it to be far more popular than any language so far. VB
provided Rapid Application Development(RAD). MFC on the other hand did
not have this goal. Its goal was to convert traditional Win32 C
programmers in very early nineties. Clearly it has served its purpose.
What you are pointing out is insignificant compared to the ease with
which VB lets you do COM development. These two are different
evnvironments going there own way for better or for worse.

---------
Ajay Kalra
***@yahoo.com

[Ed Weir (ComCast)]

"Ajay Kalra" <***@yahoo.com> wrote in message news:***@f14g2000cwb.googlegroups.com...
| There are several fundamental differences between VB and MFC. VB was
| catered to the developers without any significant experience. There is
| a reason for it to be far more popular than any language so far. VB
| provided Rapid Application Development(RAD). MFC on the other hand did
| not have this goal. Its goal was to convert traditional Win32 C
| programmers in very early nineties. Clearly it has served its purpose.
| What you are pointing out is insignificant compared to the ease with
| which VB lets you do COM development. These two are different
| evnvironments going there own way for better or for worse.
|
| ---------
| Ajay Kalra
| ***@yahoo.com
|
Seems to me that if 1/5 the effort the OP has put toward complaining had
been put to creating his own CInputBox class this would have been an article
by now instead of a ranting thread. How long are we going to pound this
nail?
- Ed.

[Ajay Kalra]

Something like this::

http://www.codeproject.com/miscctrl/cinputbox.asp


---------
Ajay Kalra
***@yahoo.com

[Tom Serface]

Yeah that :o)

Post by Ajay Kalra
http://www.codeproject.com/miscctrl/cinputbox.asp
---------
Ajay Kalra

[Tom Serface]

He doesn't even need to do that much:

http://www.codeproject.com/miscctrl/cinputbox.asp

:o)

Tom

"Ed Weir (ComCast)" <***@Maus.duh> wrote in message news:WrSdnQtn5o4UKW3eRVn-***@comcast.com...
|

Post by Ed Weir (ComCast)
Seems to me that if 1/5 the effort the OP has put toward complaining had
been put to creating his own CInputBox class this would have been an article
by now instead of a ranting thread. How long are we going to pound this
nail?

[Tom Serface]

Hi KMA,

I sort of agree with you that it would have been very easy to build more
stuff like this into MFC. There are times when I kind of wish they did, but
they didn't. What MFC does give you is a much faster program with a much
smaller footprint and it does that really well.

You could create a small .RC file with the dialogs you plan to use often and
just include the .RC, .cpp, and .h files in projects where you want to use
them. I know it's more hassle to set up, but once it's there you can use it
anywhere.

Tom

Post by KMA
OK, and now I want to use the same dialog in another project. Go through
same procedure again, making sure I drop the controls in exactly the same
place for consistancy?. Copy and paste from the resource file?
Or put it in a library? A separate dll for one dialog box? And if I want
the class statically bound?
And you really think the above take less than three minutes? I doubt it,
CString s = InputBox("Please enter your name");
Of course, you can write the function yourself. It's just a pity the MFC
group didn't take a peek at what the VB group were doing and incorporate
this very useful idea.

[Ajay Kalra]

Post by Tom Serface
a small .RC file with the dialogs you plan to use often and
just include the .RC, .cpp, and .h files in projects where you want to use
them.

I dont think its that trivial because of ID conflicts. MFC manages all
this stuff for you. VB has no concept of IDs. For a true reusable
solution, you should have a Regular DLL where IDs dont matter or have
an extension DLL which accepts IDs as parameters.

-------
Ajay Kalra
***@yahoo.com

[KMA]

I think this thread has got a bit VB centric. Many other languages give
similar functionality, like Delphi, for example.

Ajay,

What ID conflicts do you envisage? AKAIK you can pick whatever ID's you want
for the edit control, assuming the InputBox is modal. After all, nobody pays
any attention to the control IDs of the file open dialog.

Post by Ajay Kalra

Post by Tom Serface
a small .RC file with the dialogs you plan to use often and
just include the .RC, .cpp, and .h files in projects where you want to use
them.

I dont think its that trivial because of ID conflicts. MFC manages all
this stuff for you. VB has no concept of IDs. For a true reusable
solution, you should have a Regular DLL where IDs dont matter or have
an extension DLL which accepts IDs as parameters.
-------
Ajay Kalra

[Ajay Kalra]

If you plan to have a resource ID dependent code to be used in any
project(as suggested by Tom), you will need to have some resource IDs
that are not used by any of the projects. That is almost impossible to
predict. IOW, you cannot embed resource IDs in your class. It should
expect to be given the resource IDs by its client. Other possibility is
to make it in a Regular DLL, which gets its own resoruces and no
conflict is possible. VB does not have to deal with all this. I dont
know how Nish's solution mentined elsewhere takes care of this issue.

---------
Ajay Kalra
***@yahoo.com

[KMA]

I'm not quite sure I follow you.

If I make a dialog with a button, I can give whatever ID I like to the
button. whenever it's clicked I trap the event in the dialog and handle it.
It doesn't matter at all if I have another control somewhere in the app with
the same ID, as long as I don't bubble the event up for some reason.

Think about the file open dialog box. You almost certainly use this in an
app. But do you know the reasource IDs for its' controls? Or care? Of course
not.

If you're talking about the ID for the dialog resource itself, then I
circumvent this by creating my dialogs from dynamic templates, rather than
embedded templates created via rc files. Ths has the advantage that I don't
have to add bits to the rc file for projects that use the dialogs, and, more
importantly, I can put my handy dialogs into a static library and reuse them
wherever I want with minimum effort.

And therein lies my point from day 1 on this thread. Namely that MFC is
perfectly usable, but that the designers didn't seem to go the extra mile to
make it more productive to the developer. So everybody develops their own
library of "missing MFC compenents".

Another quick example that cropped up yesterday. I was using a CStringList
in MFC and in another project a (Delphi) TStringList. I wanted to use them
to make a condenced list of something containing no duplicates. With the MFC
prog I get a string, check if it's in the list already then add it if not
present. Simple enough. But with Delphi, the stringlist has a Duplicates
property which allows you to say in advance what to do about duplicate
values. So you just need to keep adding strings. Internally it does the same
thing as the MFC variant, it just makes the code a bit cleaner. Of course, I
could derive my ownstring list class in MFC and implement this feature if I
use it a lot, but with Delphi it's already there. The designers have thought
about how people are using their components and tried to make things easier
for them. You can also see this if you look at the .NET framework.

Post by Ajay Kalra
If you plan to have a resource ID dependent code to be used in any
project(as suggested by Tom), you will need to have some resource IDs
that are not used by any of the projects. That is almost impossible to
predict. IOW, you cannot embed resource IDs in your class. It should
expect to be given the resource IDs by its client. Other possibility is
to make it in a Regular DLL, which gets its own resoruces and no
conflict is possible. VB does not have to deal with all this. I dont
know how Nish's solution mentined elsewhere takes care of this issue.
---------
Ajay Kalra

[Tom Serface]

I think you'd be OK to do the canned dialog since the resource ID's can be
duplicated on different dialogs (the numbers) so long as the are not
duplicated on the same dialog. So, as long as you just assign the text for
the non-static descriptions and use standard buttons you probably won't have
too much trouble. The only trouble you may have is if the dialog ID is the
same as one you have in another dialog.

My take, it's just easier to do it for each project. It only takes a couple
of minutes and you can give each project it's own distinct look and feel.

Tom

Post by KMA
I'm not quite sure I follow you.
If I make a dialog with a button, I can give whatever ID I like to the
button. whenever it's clicked I trap the event in the dialog and handle
it. It doesn't matter at all if I have another control somewhere in the
app with the same ID, as long as I don't bubble the event up for some
reason.
Think about the file open dialog box. You almost certainly use this in an
app. But do you know the reasource IDs for its' controls? Or care? Of
course not.
If you're talking about the ID for the dialog resource itself, then I
circumvent this by creating my dialogs from dynamic templates, rather than
embedded templates created via rc files. Ths has the advantage that I
don't have to add bits to the rc file for projects that use the dialogs,
and, more importantly, I can put my handy dialogs into a static library
and reuse them wherever I want with minimum effort.
And therein lies my point from day 1 on this thread. Namely that MFC is
perfectly usable, but that the designers didn't seem to go the extra mile
to make it more productive to the developer. So everybody develops their
own library of "missing MFC compenents".
Another quick example that cropped up yesterday. I was using a CStringList
in MFC and in another project a (Delphi) TStringList. I wanted to use them
to make a condenced list of something containing no duplicates. With the
MFC prog I get a string, check if it's in the list already then add it if
not present. Simple enough. But with Delphi, the stringlist has a
Duplicates property which allows you to say in advance what to do about
duplicate values. So you just need to keep adding strings. Internally it
does the same thing as the MFC variant, it just makes the code a bit
cleaner. Of course, I could derive my ownstring list class in MFC and
implement this feature if I use it a lot, but with Delphi it's already
there. The designers have thought about how people are using their
components and tried to make things easier for them. You can also see this
if you look at the .NET framework.

[KMA]

Post by Tom Serface

Post by Tom Serface
you can give each project it's own distinct look and feel.

All too easily :)

Which is why I prefer common components. Makes it easier if you have a
marketing dept who like to tinker with the GUI elements too. Then you only
have to change one source file rather each project.

Post by Tom Serface
I think you'd be OK to do the canned dialog since the resource ID's can be
duplicated on different dialogs (the numbers) so long as the are not
duplicated on the same dialog. So, as long as you just assign the text for
the non-static descriptions and use standard buttons you probably won't
have too much trouble. The only trouble you may have is if the dialog ID
is the same as one you have in another dialog.

see below

Post by Tom Serface
My take, it's just easier to do it for each project. It only takes a
couple of minutes and you can give each project it's own distinct look and
feel.
Tom

Post by Tom Serface
I'm not quite sure I follow you.
If I make a dialog with a button, I can give whatever ID I like to the
button. whenever it's clicked I trap the event in the dialog and handle
it. It doesn't matter at all if I have another control somewhere in the
app with the same ID, as long as I don't bubble the event up for some
reason.
Think about the file open dialog box. You almost certainly use this in an
app. But do you know the reasource IDs for its' controls? Or care? Of
course not.
If you're talking about the ID for the dialog resource itself, then I
circumvent this by creating my dialogs from dynamic templates, rather
than embedded templates created via rc files. Ths has the advantage that
I don't have to add bits to the rc file for projects that use the
dialogs, and, more importantly, I can put my handy dialogs into a static
library and reuse them wherever I want with minimum effort.
And therein lies my point from day 1 on this thread. Namely that MFC is
perfectly usable, but that the designers didn't seem to go the extra mile
to make it more productive to the developer. So everybody develops their
own library of "missing MFC compenents".
Another quick example that cropped up yesterday. I was using a
CStringList in MFC and in another project a (Delphi) TStringList. I
wanted to use them to make a condenced list of something containing no
duplicates. With the MFC prog I get a string, check if it's in the list
already then add it if not present. Simple enough. But with Delphi, the
stringlist has a Duplicates property which allows you to say in advance
what to do about duplicate values. So you just need to keep adding
strings. Internally it does the same thing as the MFC variant, it just
makes the code a bit cleaner. Of course, I could derive my ownstring list
class in MFC and implement this feature if I use it a lot, but with
Delphi it's already there. The designers have thought about how people
are using their components and tried to make things easier for them. You
can also see this if you look at the .NET framework.

[Tom Serface]

Of course, you can always make the common file for dialogs you use a lot
too. :o)

Sorry... I'm taking us in circles again.

Tom

Post by KMA

Post by Tom Serface
you can give each project it's own distinct look and feel.

All too easily :)
Which is why I prefer common components. Makes it easier if you have a
marketing dept who like to tinker with the GUI elements too. Then you only
have to change one source file rather each project.

[Ajay Kalra]

Post by KMA
If you're talking about the ID for the dialog resource itself, then I
circumvent this by creating my dialogs from dynamic templates, rather than
embedded templates created via rc files.

I was talking about the dialog resource. I dont know if this would
solve the problems. Dont you still need an ID for the dialog?

------
Ajay Kalra
***@yahoo.com

[Tom Serface]

Yeah and that could conflict. That's why for MFC they reserved a bunch of
ranges.

Of course, you can do this for your "own" stuff as well. Just use an ID
that is higher than the ones MFC will assign to dialogs when you create
them. Then you can include your .rc file and, in most cases, the dialogs in
there won't conflict. Nothing's perfect though.

Tom

Post by Ajay Kalra

Post by KMA
If you're talking about the ID for the dialog resource itself, then I
circumvent this by creating my dialogs from dynamic templates, rather than
embedded templates created via rc files.

I was talking about the dialog resource. I dont know if this would
solve the problems. Dont you still need an ID for the dialog?
------
Ajay Kalra

[Ajay Kalra]

That was my original thought. We ran into these issues head on and were
very problematic for our project.

The sure shot way to make it reusable is to have a Regular DLL with
this code. However I need to look at Nish's code and Dynamic templates
mentioned by KMA to see what all they offer.

---------
Ajay Kalra
***@yahoo.com

[KMA]

Tom,

I don't use embedded resources. So I don't have to worry about locating
dialog resources in the exe. This means I don't need the (integer) ID
therefore there is no conflict possible.

When I need to show a dialog I build it's template in memory, I don't load
it from the exe.

CDynDialogEx - A fine class written by someone else who found the MFC a tad
limited, but unlike me, had the brains to develop a rather exquisite
solution. Take a peek, and I guarantee you'll never look back. Honest.

Post by Tom Serface
Yeah and that could conflict. That's why for MFC they reserved a bunch of
ranges.
Of course, you can do this for your "own" stuff as well. Just use an ID
that is higher than the ones MFC will assign to dialogs when you create
them. Then you can include your .rc file and, in most cases, the dialogs
in there won't conflict. Nothing's perfect though.
Tom

Post by Ajay Kalra

Post by KMA
If you're talking about the ID for the dialog resource itself, then I
circumvent this by creating my dialogs from dynamic templates, rather than
embedded templates created via rc files.

I was talking about the dialog resource. I dont know if this would
solve the problems. Dont you still need an ID for the dialog?
------
Ajay Kalra

[Tom Serface]

Yeah, I looked at that. Youy're right! It looks useful. Glad you got a
solution and I hope MFC grows on you as you learn more about it. Many of us
consider it almost like a separate version of C++ and wouldn't want to live
without it.

Tom

Post by KMA
Tom,
I don't use embedded resources. So I don't have to worry about locating
dialog resources in the exe. This means I don't need the (integer) ID
therefore there is no conflict possible.
When I need to show a dialog I build it's template in memory, I don't load
it from the exe.
CDynDialogEx - A fine class written by someone else who found the MFC a
tad limited, but unlike me, had the brains to develop a rather exquisite
solution. Take a peek, and I guarantee you'll never look back. Honest.

[KMA]

I guess your perspective on MFC depends upon where you came from. If you
were used to writing Win apps starting with WinMain, then adding all your
controls by hand, routing your own messages etc, then MFC represents a huge
leap forward in productivity. On the other hand, if you come form a dev env
with a well developed rich class library, then it's surprising not to find
your favourite "indispensable" classes and functions.
The F in MFC should be interpreted quite literally. They are a foundation
upon which you will have to build, whereas (for example) Delphi gives you
the foundation, four walls, a roof and a satellite dish to stick on top all
out of the box. Plus a gazzion other extended components that other people
have developed.

MFC gets you into the habit of writing your own, which probably isn't a bad
thing if you're not short of time. But if you are under time pressure MFC
doesn't deliver the same level of productivity that other dev envs can.
Until you've developed your own class library on top, that is.

Post by Tom Serface
Yeah, I looked at that. Youy're right! It looks useful. Glad you got a
solution and I hope MFC grows on you as you learn more about it. Many of
us consider it almost like a separate version of C++ and wouldn't want to
live without it.
Tom

Post by KMA
Tom,
I don't use embedded resources. So I don't have to worry about locating
dialog resources in the exe. This means I don't need the (integer) ID
therefore there is no conflict possible.
When I need to show a dialog I build it's template in memory, I don't
load it from the exe.
CDynDialogEx - A fine class written by someone else who found the MFC a
tad limited, but unlike me, had the brains to develop a rather exquisite
solution. Take a peek, and I guarantee you'll never look back. Honest.

[KMA]

No you don't.
I assume you're talking about the line in most dialog classes that goes:

enum { IDD = IDD_COATPOS_DLG };

where IDD_COATPOS_DLG is unique amongst its' peers.

IIRC this ID is only needed in order to locate the embedded resource. You'll
never see a message with this ID as the source, whereas you will see
messages from controls within the dialog. If you look with Spy you'll see
that there is no Control ID for the dialog itself.

Since I don't use embedded resources, I don't need an identfier to locate
it.

If you're interested in this idea, take a look at CDynDialogEx. If you
manage to get through the tutorial you will be well equipped to solve the
maintenance headache of having rc file fragments littered throughout.

Also it allows you to implement form inheritance, which is something else
the MFC designers thought we wouldn't want either.

Post by Ajay Kalra

Post by KMA
If you're talking about the ID for the dialog resource itself, then I
circumvent this by creating my dialogs from dynamic templates, rather than
embedded templates created via rc files.

I was talking about the dialog resource. I dont know if this would
solve the problems. Dont you still need an ID for the dialog?
------
Ajay Kalra

[Ajay Kalra]

I still dont get it that how you are going to avoid the conflict. Say I
have several existing projects which use tons of resources(all
extension DLLs). All resoruces in these projects can be seen in any
module using dynamic chaning (CDynLinkLibrary). How can you guarantee
that you can have a resource ID that is not used in this project? This
is a common developement scenario of a project. Somewhere you need an
ID. You will need to tweak the project to ensure an ID is available.

------------
Ajay Kalra
***@yahoo.com

[KMA]

Ajay,

If you're talking about resources in general, you're right.

For example if you have string resources in several modules with the same ID
then you need to be able to load the correct one. This can still be done by
"activating" a particular module before loading (AfxSetRsourceHandle). This
applies to all resources that are bound into modules.

But I'm talking about constructing dialogs without using bound resources. I
don't have any ID respresenting the dialog. Instead I create a dialog
template in memory "by hand" (well, in code). I then dynamically add
controls to it and message handlers and so on. So, you see, no embedded
resource means no ID which means no conflict.

The other advantage to this is that I can put my dialog classes into a
static library, which reduces the mess of distributing dlls. If you stick to
embedded resource dialogs then you can't do this without having to do some
fancy resource includes for the client project, and this is where the
conflict you speak of would arise.

The DynDialog tutorial explains this much better than me.

Tom had a look, and he liked it.

Post by Ajay Kalra
I still dont get it that how you are going to avoid the conflict. Say I
have several existing projects which use tons of resources(all
extension DLLs). All resoruces in these projects can be seen in any
module using dynamic chaning (CDynLinkLibrary). How can you guarantee
that you can have a resource ID that is not used in this project? This
is a common developement scenario of a project. Somewhere you need an
ID. You will need to tweak the project to ensure an ID is available.
------------
Ajay Kalra

[Ajay Kalra]

KMA,

I must confess that I have never had a chance to create a dialog in
memory w/o an ID. I will need to look into it. If it is something
viable, its a nice way to accomplish what you had earlier mentioned
about creating a reusable dialog. IDs of the controls have really no
meaning as long as these are distinct within the dialog.

Thanks for letting me know.

-----------
Ajay Kalra
***@yahoo.com

[Joseph M. Newcomer]

Copy and paste is a nice methodology.

You can't put it in a DLL and have it statically bound; the concepts are incompatible.

Yes, it takes longer than InputBox to write, but as already established, that is a
pointless comparison because InputBox doesn't exist, so why worry about it?

The point is that the VB group is dealing with a different audience than the MFC group.
Frankly, the number of times I've needed InputBox funcitonality is so small that I don't
mind taking the three minutes to do it...

Never mind. I just sat here with a stopwatch and did it.. I apologize; my three minute
estimate was wrong. It took me one minute and forty seconds to create the dialog, the
variables, and the class.
joe

Post by KMA
OK, and now I want to use the same dialog in another project. Go through
same procedure again, making sure I drop the controls in exactly the same
place for consistancy?. Copy and paste from the resource file?
Or put it in a library? A separate dll for one dialog box? And if I want the
class statically bound?
And you really think the above take less than three minutes? I doubt it, but
CString s = InputBox("Please enter your name");
Of course, you can write the function yourself. It's just a pity the MFC
group didn't take a peek at what the VB group were doing and incorporate
this very useful idea.

Post by Joseph M. Newcomer
You have not said much about what you expect here. It sounds like you are
willing to have
a dialog pop up and get the input. It should take you under three minutes
to create this.
(1) Create a dialog
(2) Place an edit control on the dialog
(3) Resize the dialog to minimum size (this may involve rearranging the buttons)
(4) Create a dialog class for it, for example, CMyInputDialog
(5) In the dialog class, create a value member variable, a CString, coupled to the edit
control. For example, call it m_Input.
CMyInputDialog dlg;
if(dlg.DoModal() == IDOK)
... use dlg.m_Input;
Done.
joe

Post by s***@gmail.com
Hi I need to input certain text value from a user. This is a MFC
application and I am not able to find a control which can do this. Do
I _have_ to write a custom Dialog box or is there something like
MessageBox which can also take user input ?
Regards
Sandeep

Joseph M. Newcomer [MVP]
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

[KMA]

see below...

Post by Joseph M. Newcomer
Copy and paste is a nice methodology.

So why write a class for anything? If you need to change it you can just
amend all the pasted versions. I can hardly believe you wrote that.

Post by Joseph M. Newcomer
You can't put it in a DLL and have it statically bound; the concepts are incompatible.

Exactly. The problem is that you can't include resources in the static
library, which you well know, even if you seem reluctant to admit it.

Post by Joseph M. Newcomer
Yes, it takes longer than InputBox to write, but as already established, that is a
pointless comparison because InputBox doesn't exist, so why worry about it?

It's not pointless. *If* the MFC designers had included it, it would be
used. I suspect quite often, as AfxMessageBox is used by most MFC programers
now, as as "InputBox" type methods are routinely used by other programmers
using different tools.

Post by Joseph M. Newcomer
The point is that the VB group is dealing with a different audience than the MFC group.
Frankly, the number of times I've needed InputBox funcitonality is so small that I don't
mind taking the three minutes to do it...

Then maybe we don't work on the same kinds of programs. But imagine you were
supplying a static lib to a customer, and you must have some place for
parameter input. What do you do then? Tell them to make sure that every
calling exe has a chunk of rc data that your dialog class expects to be
bound in the exe? Force them to use a(nother) DLL?

Post by Joseph M. Newcomer
Never mind. I just sat here with a stopwatch and did it.. I apologize; my three minute
estimate was wrong. It took me one minute and forty seconds to create the dialog, the
variables, and the class.

Since you're being petulant, one minute forty is still many times longer
than (hang on, I'll type it now).... 12 seconds, and I'm a two finger
typist.

The solution you proposed would be longer in the short run, and much longer
in the long-run.

You appear to have misunderstood the OPs' question and have subsequently
tried to subvert the thread to justify your misunderstanding. Even to the
point of advocating copy and pasting common code. Not what I expected at
all.

Post by Joseph M. Newcomer
joe

Post by KMA
OK, and now I want to use the same dialog in another project. Go through
same procedure again, making sure I drop the controls in exactly the same
place for consistancy?. Copy and paste from the resource file?
Or put it in a library? A separate dll for one dialog box? And if I want the
class statically bound?
And you really think the above take less than three minutes? I doubt it, but
CString s = InputBox("Please enter your name");
Of course, you can write the function yourself. It's just a pity the MFC
group didn't take a peek at what the VB group were doing and incorporate
this very useful idea.

Post by Joseph M. Newcomer
You have not said much about what you expect here. It sounds like you are
willing to have
a dialog pop up and get the input. It should take you under three minutes
to create this.
(1) Create a dialog
(2) Place an edit control on the dialog
(3) Resize the dialog to minimum size (this may involve rearranging the buttons)
(4) Create a dialog class for it, for example, CMyInputDialog
(5) In the dialog class, create a value member variable, a CString, coupled to the edit
control. For example, call it m_Input.
CMyInputDialog dlg;
if(dlg.DoModal() == IDOK)
... use dlg.m_Input;
Done.
joe

Post by s***@gmail.com
Hi I need to input certain text value from a user. This is a MFC
application and I am not able to find a control which can do this. Do
I _have_ to write a custom Dialog box or is there something like
MessageBox which can also take user input ?
Regards
Sandeep

Joseph M. Newcomer [MVP]
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

[Joseph M. Newcomer]

See below..

Post by KMA
see below...

Post by Joseph M. Newcomer
Copy and paste is a nice methodology.

So why write a class for anything? If you need to change it you can just
amend all the pasted versions. I can hardly believe you wrote that.

Post by Joseph M. Newcomer
You can't put it in a DLL and have it statically bound; the concepts are incompatible.

Exactly. The problem is that you can't include resources in the static
library, which you well know, even if you seem reluctant to admit it.

****
I've never been reluctant to admit that resources can't be put into static libraries; in
fact, I think this is one of the significant holes in the whole Microsoft methodology.
There should be a way to link in precompiled .res files, and the resource symbols should
even be relocatable. But that's not something we expect to see done right in our
lifetimes.
****

Post by KMA

Post by Joseph M. Newcomer
Yes, it takes longer than InputBox to write, but as already established, that is a
pointless comparison because InputBox doesn't exist, so why worry about it?

It's not pointless. *If* the MFC designers had included it, it would be
used. I suspect quite often, as AfxMessageBox is used by most MFC programers
now, as as "InputBox" type methods are routinely used by other programmers
using different tools.

****
Sure it would be used. Sure, it might be nice to have it. But it doesn't have it, but
you are talking under two minutes to re-create it. This is not a major issue.
*****

Post by KMA

Post by Joseph M. Newcomer
The point is that the VB group is dealing with a different audience than the MFC group.
Frankly, the number of times I've needed InputBox funcitonality is so small that I don't
mind taking the three minutes to do it...

Then maybe we don't work on the same kinds of programs. But imagine you were
supplying a static lib to a customer, and you must have some place for
parameter input. What do you do then? Tell them to make sure that every
calling exe has a chunk of rc data that your dialog class expects to be
bound in the exe? Force them to use a(nother) DLL?

*****
Well, if I really needed to do a static library, I'd consider duing a DialogBoxIndirect
call. But I'd be disinclined to put something like this in a static library because of
the deficiencies of the VS environment. After all, the only reason all the other controls
work is because they are already in DLLs, so there is a recognition that you can't put
CFileDialog, CFontDialog, CColorDialog, CPrintDialog, etc. in a statically-linked
environment; only a DLL works. So I'd more likely put it in a DLL, and if someone really,
really needed to do static linking, they can add the necessary resources by hand as well.
I know it's a pain, which is why I'd use a DLL. I haven't delivered a serious product
that didn't use DLLs in so long that it doesn't seem to be a problem. My clients use DLLs
because they want to avoid opening their code but want to use a GPL subroutine, or because
they have code so proprietary that even under NDA I'm not allowed to see it so they give
me a DLL to interface to. Or they are using a third-party DLL to get some sophisticated
control system. I am not sure why there is such a reluctance to use DLLs; they are a fact
of life.
****

Post by KMA

Post by Joseph M. Newcomer
Never mind. I just sat here with a stopwatch and did it.. I apologize; my three minute
estimate was wrong. It took me one minute and forty seconds to create the dialog, the
variables, and the class.

Since you're being petulant, one minute forty is still many times longer
than (hang on, I'll type it now).... 12 seconds, and I'm a two finger
typist.

****
Yes, but you are arguing that because it is trivial in VB it has to be trivial in MFC.
There are *lots* of things that are trivial in VB that are not trivial in MFC, such as
interfacing to ActiveX controls, using embedded documents, etc. VB has lots of support
that makes a lot of things easy. But we don't expect any of these in MFC, so focussing on
a trivial feature instead of a major feature seems odd.
****

Post by KMA
The solution you proposed would be longer in the short run, and much longer
in the long-run.
You appear to have misunderstood the OPs' question and have subsequently
tried to subvert the thread to justify your misunderstanding. Even to the
point of advocating copy and pasting common code. Not what I expected at
all.

*****
Copy and paste is still a good methodology. However, creating a DLL once takes only a few
more minutes.

I was not subverting the thread; the point seemed to be that MFC owes VB programmers a
degree of simplicity that MFC never pretended to provide. I don't follow the logic of
this at all. Particularly when the solution is trivial.
****

Post by KMA

Post by Joseph M. Newcomer
joe

Post by KMA
OK, and now I want to use the same dialog in another project. Go through
same procedure again, making sure I drop the controls in exactly the same
place for consistancy?. Copy and paste from the resource file?
Or put it in a library? A separate dll for one dialog box? And if I want the
class statically bound?
And you really think the above take less than three minutes? I doubt it, but
CString s = InputBox("Please enter your name");
Of course, you can write the function yourself. It's just a pity the MFC
group didn't take a peek at what the VB group were doing and incorporate
this very useful idea.

Post by Joseph M. Newcomer
You have not said much about what you expect here. It sounds like you are
willing to have
a dialog pop up and get the input. It should take you under three minutes
to create this.
(1) Create a dialog
(2) Place an edit control on the dialog
(3) Resize the dialog to minimum size (this may involve rearranging the buttons)
(4) Create a dialog class for it, for example, CMyInputDialog
(5) In the dialog class, create a value member variable, a CString,
coupled to the edit
control. For example, call it m_Input.
CMyInputDialog dlg;
if(dlg.DoModal() == IDOK)
... use dlg.m_Input;
Done.
joe

Post by s***@gmail.com
Hi I need to input certain text value from a user. This is a MFC
application and I am not able to find a control which can do this. Do
I _have_ to write a custom Dialog box or is there something like
MessageBox which can also take user input ?
Regards
Sandeep

Joseph M. Newcomer [MVP]
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

[KMA]

Thanks for getting back, I was beginning to think this thread had crawled
off and died. I''ll have to copy and paste from below for clarity, not to
deliberately take your comments out of context.

Post by Joseph M. Newcomer
Well, if I really needed to do a static library, I'd consider duing a DialogBoxIndirect
call.

Which is what I recommeded to the OP in my first post on the thread. It
makes a reusable solution, but hardly a two minute job. I wonder how many
other MFC programmers have followed parallel lines to augment the MFC in a
similar way. Now, I'm not advocating that MS should have released a new
version of MFC every 6 months. Just pointing out (to the OP) that this
functionality is missing. I then rail against any solution that involves
either distributing an extra dll or having to include resources in calling
exes.

Post by Joseph M. Newcomer
So I'd more likely put it in a DLL, and if someone really,
really needed to do static linking, they can add the necessary resources by hand as well.
I know it's a pain, which is why I'd use a DLL

And presumably hope that they use early binding so that if they try to
distribute without the dll then they get a message on app load. Or that if
they use late binding that they check the return value from LoadLibrary.
Both of which can be expected from disciplined progammers. But who can
guarantee that their code will be used in such a way? Or that your dll will
be included in the install. Or that a bug fixed version will be sent out
with a patch. Or that everything will be updated and work when the interface
to the dll *has* to change. In the ideal world, of course, none of these
things happen. But I know that you've been in software long enough to
appreciate that mismatching dlls represent a recurring problem.

Post by Joseph M. Newcomer
Yes, but you are arguing that because it is trivial in VB it has to be trivial in MFC.
...the point seemed to be that MFC owes VB programmers a
degree of simplicity that MFC never pretended to provide. I don't follow the logic of
this at all.

I only chose VB because it's a common language that most people have heard
of. And the reason that it's popular is because it's productive. Delphi
would be another good example.

My argument, or complaint, if you like is this:
The reason we use MFC at all is because we don't want to write our own
framework to call the WinAPI. Because we want to save time. When MS promote
MFC they use precisely this rationale. Even at the inception of MFC, the
InputBox functionality was available in other languages. But it wasn't
included, probably because someone thought that the IDE was so good that
programmers would be pleased to add the InputBox functionality to every
project, and tailor it accordingly. But the reality is that my apps are
complicated enough, I just want a one line solution to grab a bit of input
and get on with the job in hand. No worries about resource includes, or dll
distribution. I don't care if the exe size jumps up a tad. In the long run,
I want to save time.

I responded to the original poster because I'd done excactly the same,
namely look for a function that surely must be there. Find it isn't then
devise my own solution. From a pragmatic point of view you just have to
accept that MFC provides the functionality that it does, and then it's up to
the MFC consumer. "F" is for "Foundation", after all. But I can't see why
you would try to argue that the decision not to include the InputBox type
functionality was not a bad decision. That somehow the MFC is better off
without it.

Post by Joseph M. Newcomer
See below..

Post by KMA
see below...

Post by Joseph M. Newcomer
Copy and paste is a nice methodology.

So why write a class for anything? If you need to change it you can just
amend all the pasted versions. I can hardly believe you wrote that.

Post by Joseph M. Newcomer
You can't put it in a DLL and have it statically bound; the concepts are incompatible.

Exactly. The problem is that you can't include resources in the static
library, which you well know, even if you seem reluctant to admit it.

****
I've never been reluctant to admit that resources can't be put into static libraries; in
fact, I think this is one of the significant holes in the whole Microsoft methodology.
There should be a way to link in precompiled .res files, and the resource symbols should
even be relocatable. But that's not something we expect to see done right in our
lifetimes.
****

Post by KMA

Post by Joseph M. Newcomer
Yes, it takes longer than InputBox to write, but as already established, that is a
pointless comparison because InputBox doesn't exist, so why worry about it?

It's not pointless. *If* the MFC designers had included it, it would be
used. I suspect quite often, as AfxMessageBox is used by most MFC programers
now, as as "InputBox" type methods are routinely used by other programmers
using different tools.

****
Sure it would be used. Sure, it might be nice to have it. But it doesn't have it, but
you are talking under two minutes to re-create it. This is not a major issue.
*****

Post by KMA

Post by Joseph M. Newcomer
The point is that the VB group is dealing with a different audience than the MFC group.
Frankly, the number of times I've needed InputBox funcitonality is so
small that I don't
mind taking the three minutes to do it...

Then maybe we don't work on the same kinds of programs. But imagine you were
supplying a static lib to a customer, and you must have some place for
parameter input. What do you do then? Tell them to make sure that every
calling exe has a chunk of rc data that your dialog class expects to be
bound in the exe? Force them to use a(nother) DLL?

*****
Well, if I really needed to do a static library, I'd consider duing a DialogBoxIndirect
call. But I'd be disinclined to put something like this in a static library because of
the deficiencies of the VS environment. After all, the only reason all the other controls
work is because they are already in DLLs, so there is a recognition that you can't put
CFileDialog, CFontDialog, CColorDialog, CPrintDialog, etc. in a statically-linked
environment; only a DLL works. So I'd more likely put it in a DLL, and if someone really,
really needed to do static linking, they can add the necessary resources by hand as well.
I know it's a pain, which is why I'd use a DLL. I haven't delivered a serious product
that didn't use DLLs in so long that it doesn't seem to be a problem. My clients use DLLs
because they want to avoid opening their code but want to use a GPL subroutine, or because
they have code so proprietary that even under NDA I'm not allowed to see it so they give
me a DLL to interface to. Or they are using a third-party DLL to get some sophisticated
control system. I am not sure why there is such a reluctance to use DLLs; they are a fact
of life.
****

Post by KMA

Post by Joseph M. Newcomer
Never mind. I just sat here with a stopwatch and did it.. I
apologize;
my three minute
estimate was wrong. It took me one minute and forty seconds to create
the
dialog, the
variables, and the class.

Since you're being petulant, one minute forty is still many times longer
than (hang on, I'll type it now).... 12 seconds, and I'm a two finger
typist.

****
Yes, but you are arguing that because it is trivial in VB it has to be trivial in MFC.
There are *lots* of things that are trivial in VB that are not trivial in MFC, such as
interfacing to ActiveX controls, using embedded documents, etc. VB has lots of support
that makes a lot of things easy. But we don't expect any of these in MFC, so focussing on
a trivial feature instead of a major feature seems odd.
****

Post by KMA
The solution you proposed would be longer in the short run, and much longer
in the long-run.
You appear to have misunderstood the OPs' question and have subsequently
tried to subvert the thread to justify your misunderstanding. Even to the
point of advocating copy and pasting common code. Not what I expected at
all.

*****
Copy and paste is still a good methodology. However, creating a DLL once takes only a few
more minutes.
I was not subverting the thread; the point seemed to be that MFC owes VB programmers a
degree of simplicity that MFC never pretended to provide. I don't follow the logic of
this at all. Particularly when the solution is trivial.
****

Post by KMA

Post by Joseph M. Newcomer
joe

Post by KMA
OK, and now I want to use the same dialog in another project. Go through
same procedure again, making sure I drop the controls in exactly the same
place for consistancy?. Copy and paste from the resource file?
Or put it in a library? A separate dll for one dialog box? And if I want the
class statically bound?
And you really think the above take less than three minutes? I doubt it, but
CString s = InputBox("Please enter your name");
Of course, you can write the function yourself. It's just a pity the MFC
group didn't take a peek at what the VB group were doing and incorporate
this very useful idea.

Post by Joseph M. Newcomer
You have not said much about what you expect here. It sounds like you are
willing to have
a dialog pop up and get the input. It should take you under three minutes
to create this.
(1) Create a dialog
(2) Place an edit control on the dialog
(3) Resize the dialog to minimum size (this may involve rearranging
the
buttons)
(4) Create a dialog class for it, for example, CMyInputDialog
(5) In the dialog class, create a value member variable, a CString,
coupled to the edit
control. For example, call it m_Input.
CMyInputDialog dlg;
if(dlg.DoModal() == IDOK)
... use dlg.m_Input;
Done.
joe

Post by s***@gmail.com
Hi I need to input certain text value from a user. This is a MFC
application and I am not able to find a control which can do this. Do
I _have_ to write a custom Dialog box or is there something like
MessageBox which can also take user input ?
Regards
Sandeep

Joseph M. Newcomer [MVP]
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

[David Crow]

See here:

http://voidnish.com/articles/ShowArticle.aspx?code=inputbox01

Post by s***@gmail.com
Hi I need to input certain text value from a user. This is a MFC
application and I am not able to find a control which can do this. Do
I _have_ to write a custom Dialog box or is there something like
MessageBox which can also take user input ?

[Ajay Kalra]

That pretty much sums it up.

---------
Ajay Kalra
***@yahoo.com