|
I thnk you forgot the L prefix.
Use the best guess
|
|
|
|
|
That isnt going to work.
As Richrd says it needs to be const wchar_t* string = L"string"; or at the vey least use the T() macro and use tchars.
==============================
Nothing to say.
|
|
|
|
|
Yes, I realise that now. 
I've been avoiding wide-char & unicode for as long as possible because it does my frickin' head in. Only now am I coming to regret not dealing with it sooner. 
"It's true that hard work never killed anyone. But I figure, why take the chance." - Ronald Reagan
That's what machines are for.
Got a problem?
Sleep on it.
|
|
|
|
|
Avoiding unicode? Why, its great! Really, all the languages, all the localisation taken care of, propper strings. No messing around! Go for it! 
==============================
Nothing to say.
|
|
|
|
|
The problem isn't unicode, the problem is (was) patchy support with certain windows APIs
having to switch between different encodings to get API-X to behave then switch back again. 
"It's true that hard work never killed anyone. But I figure, why take the chance." - Ronald Reagan
That's what machines are for.
Got a problem?
Sleep on it.
|
|
|
|
|
strcpy? Ever looked at that? Even beter strncpy, is that what you mean?
For example;
char mystr[100];
memset(mystr, 0, 100);
strcpy(mystr, "ask a better question");
==============================
Nothing to say.
|
|
|
|
|
Erudite_Eric wrote: char mystr[100];
memset(mystr, 0, 100);
strcpy(mystr, "ask a better question");
I have always held that less code is better code. When doing this kind of thing I prefer the syntax:
char mystr[100] = {0};
strcpy(mystr, "ask a better question");
which I think is clearer and lets the compiler do all the work.
[Also I would use strcpy_s() and probably several other stylistic issues...]
--
Harvey
|
|
|
|
|
Yeah, I actually allocate all arrays on the heap because buffer overruns are tracked better and dont trash the stack making it easier to debug so I always have the memset.
Of course dont forget the compiler is just doing the memset for you, it is invisible, but still takes place so isnt any different when the code actually runs.
==============================
Nothing to say.
|
|
|
|
|
Have a look at
char[]
Char[] are used to store ASCII string in C.
|
|
|
|
|
Hi,
I have single line edit control as a member of a modal dialog box
I attach the CEdit object to the accompanying EDTITEXT resource via DDX_CONTROL
I then use DDX_TEXT to initialize a CString to read in the data However
When I invoke UpdateData(TRUE) to retrieve the text I get nothing
First the resource definition of dialog and control that are members
IDD_DIALOG4 DIALOGEX 0, 0, 316, 180
STYLE DS_SETFONT | DS_MODALFRAME | DS_FIXEDSYS | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU
CAPTION "Program Debug"
FONT 8, "MS Shell Dlg", 400, 0, 0x1
BEGIN
LTEXT "Program Name",IDC_STATIC5,60,21,40,8
EDITTEXT IDC_EDIT3,60,40,50,14
LTEXT "Job Name",IDC_STATIC9,200,21,40,8
EDITTEXT IDC_EDIT4,200,40,50,14
LTEXT "Program Location",IDC_STATIC7,60,100,60,8
EDITTEXT IDC_EDIT5,60,120,50,14
LTEXT "Starting Address",IDC_STATIC8,200,100,60,8
EDITTEXT IDC_EDIT6,200,120,50,14
PUSHBUTTON "Process",IDC_PUSH,130,150,50,15
END
Next class definition for this dialog entry which has CString members to hold the data
class Cprogdialog : public CDialog
{
DECLARE_DYNAMIC(Cprogdialog)
public:
void Process();
Cprogdialog(CWnd* pParent = NULL); BOOL OnInitDialog();
virtual ~Cprogdialog();
CStatic sprogname; CEdit eprogname; CStatic sjobname;
CEdit ejobname;
CStatic slocation;
CEdit elocation;
CStatic saddr;
CEdit eaddr;
CButton process;
CString progname;
CString jobname;
CString location;
CString addr;
protected:
virtual void DoDataExchange(CDataExchange* pDX);
DECLARE_MESSAGE_MAP()
};
Then the DoDAtaExchange to attach the Cwnd type objects UpdateData(False) and reterive the
Data UpdateData(TRUE);
void Cprogdialog::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
DDX_Control(pDX,IDC_STATIC5,sprogname);
DDX_Control(pDX,IDC_EDIT3,eprogname);
DDX_Control(pDX,IDC_STATIC9,sjobname);
DDX_Control(pDX,IDC_EDIT4,ejobname);
DDX_Control(pDX,IDC_STATIC7,slocation);
DDX_Control(pDX,IDC_EDIT5,elocation);
DDX_Control(pDX,IDC_STATIC8,saddr);
DDX_Control(pDX,IDC_EDIT6,eaddr);
DDX_Control(pDX,IDC_PUSH,process);
DDX_Text(pDX,IDC_EDIT3,progname);
DDX_Text(pDX,IDC_EDIT4,jobname);
DDX_Text(pDX,IDC_EDIT5,location);
DDX_Text(pDX,IDC_EDIT6,addr);
}
I invoke UpdateData(FALSE); to attach the CWnd type objects in the OninitDialog override
And when the user hits the "process" button I read in the data via UpdateData(TRUE);
I don't think I have to initialize the CString members I am using to retrieve the the data from the
EDTITEXT by using UpdateData(FALSE); and TRUE I Should be able to attach and reterive the data
regardless the progname and jobname CString members wich I use DDX_TEXT to initialize and reterive data don't have the data in them
|
|
|
|
|
With UpdateData() being the source of so many misunderstandings, why not just stick with the tried and true SetWindowText() and GetWindowText()?
I've never actually tried mapping a control to two different variables (i.e., using both DDX_Control and DDX_Text on the same control).
Do the contents of IDC_STATIC5, IDC_STATIC7, IDC_STATIC8, or IDC_STATIC9 ever change?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
modified 15-Apr-13 15:29pm.
|
|
|
|
|
Thank you worked just fine
|
|
|
|
|
UpdateData() is a reasonable way to do it, especially if the data is exported out of the scope of the dlg.
I have mapped a control to a control variable and text variable as routine. It works fine with no problems. I believe that there are Microsoft examples that do this as well...
--
Harvey
|
|
|
|
|
ForNow wrote:
DDX_Control(pDX,IDC_EDIT3,eprogname);
...
DDX_Text(pDX,IDC_EDIT3,progname);
I do not think you should be duplicating these controls in different DDX_xxx statements.
It would also help if you put your resource script between <pre> tags, same as your code.
Use the best guess
|
|
|
|
|
Yes that's probably not right thanks
|
|
|
|
|
It's really bad form to use this sort of naming in projects. None of those names have any significance in terms of what they are supposed to represent and, as you have discovered to your cost, it's easy to end up with basic errors such as the above.
Use the best guess
|
|
|
|
|
Richard I thought the names were meaningful
I am writing a Windows MFC/C++ front end the the Hercules MainFrame Emulator
I am using named pipes to communicate with C console applicaton Hercules
the data names Jobname and Progname are the Jobname and Progname to be traced
|
|
|
|
|
ForNow wrote: I thought the names were meaningful
I was alluding to your dialog controls IDC_EDIT3, IDC_EDIT4 etc.
Use the best guess
|
|
|
|
|
[Agree 100% with this.]
To elaborate, the resource.h constants (ie. IDC_xxx) should have meaningful names, be numerically unique, the control/value variable names should be meaningful as well, and clearly related to the resource.h constants.
--
Harvey
|
|
|
|
|
Richard MacCutchan wrote: ForNow wrote:
DDX_Control(pDX,IDC_EDIT3,eprogname);
...
DDX_Text(pDX,IDC_EDIT3,progname);
I do not think you should be duplicating these controls in different DDX_xxx statements.
Hmmm ... second high ranking person to say this.
This is not a problem. It is supported and works fine. I have done it many times.
--
Harvey
|
|
|
|
|
It's some years since I wrote any MFC code, but I don't quite understand what's going on here. Surely, if you map the same control to different variables then it is potentially going to end up with some items getting updated with the wrong values. Or do I need to go back and study DDX macros again?
Use the best guess
|
|
|
|
|
DDX_Text is effectively a macro that does [Set|Get]WindowText on the window with given control ID and the given string.
DDX_Control gets a pointer to the window with given control ID, casts it to the appropriate MFC class, and assigns it to the given variable (which is a CEdit in this case).
It's perfectly safe and common practice to have both data and control members of the same GUI element, and has been since MFC 1.0 back in the early 90s.
|
|
|
|
|
Thanks, that makes more sense, but I'm still not sure what the OP's problem is - do you?
Use the best guess
|
|
|
|
|
No, the posted code looks fine, stylistic issues aside, so more information would be needed, in particular OnInitDialog and the button click message handler, but every place where UpdateData is called would need to be checked, as it's a quite common to overwrite the data you want before reading it, which is what I suspect happens here.
Personally, I think that using GetWindowText - which seems to work - makes more sense until one is more familiar with MFC and all its horribleness with magic macros. Use DDX_Control and get and set your data via the control instead.
|
|
|
|
|
Exactly - thanks for responding. I couldn't have given a better answer.
--
Harvey
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
