|
Objective-C does.
Standard C, no.
"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.
|
|
|
|
|
|
No sign of ++ in the OP heading. That's why I didn't mention it.
"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.
|
|
|
|
|
const char* string = "string";
If you want a string that is not constant, that would be assigned differently, and the answer would depend on whether you mean "assign memory space" or "assign the characters forming the string" when you say "assign", as these are two separate activities in C.
What do you want to know? What have you tried? What books and/or articles have you read, and what is it you do not understand? Who was that masked stranger?
|
|
|
|
|
Here is wide character string version for international users.
const wchar_t* string = "string";
Unicode/MBCS gets very messy developing on Windows, dependent on whether UNICODE is defined at compile time.
see this article for a comprehensive explanation.
What-are-TCHAR-WCHAR-LPSTR-LPWSTR-LPCTSTR-etc?
"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.
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
