|
Am study a little bit the problem and I found that LPCSTR is const char* and I try it to modify with lpszString = lpszStringInit ... I'm wrong ?
|
|
|
|
|
I try also to modify LPCTSTR lpszString; data member to LPSTR lpszString; but I don't know how to copy an LPCTSTR to LPSTR ...
|
|
|
|
|
Is your code compiling?? and put a debug point at
Flaviu2 wrote: lpszString = lpszStringInit;
and see if the value is getting pased
Every new day is another chance to change your life.
|
|
|
|
|
In most of cases, but I meet a situation that in lpszString I have bugs ...
|
|
|
|
|
|
|
|
Syntactically it's correct. Semantically however... only you can say if it is.
What you are doing there is take a pointer to a string and copy it to another pointer. Now both pointers point to the same string. This may be ok, but what if the argument passed to this function was a temporary object and is deleted later? In that case the pointer lpszString in your class will be invalid! Or, even worse, if the string later gets changed somewhere, this will effect your ItemData struct as well! Do you want that?
Advice: Unless you are totally certain no one else but you will ever use this struct ItemData and potentially use it in the way described above, you should take precautions against that: instead of just copying the pointers, you should copy the entire string! Of course, if you do that you should also delete that string in your destructor. It should be roughly like this (didn't actually try it out):
CMyControl::ItemData::ItemData(LPCTSTR lpszStringInit)
{
if (lpszStringInit != 0 {
std::size_t length = _tcslen(lpszStringInit);
lpszString = new TCHAR[length+1];
_tcscpy(lpszString, lpszStringInit);
}
else {
lpszString = 0;
}
}
CMyControl::ItemData::~ItemData() {
delete [] lpszString;
}
Now you're sure your ItemData object contains it's own copy that cannot be changed or deleted from the outside, no matter who uses this struct. And you know this copy will be deleted exactly when the ItemData object gets deleted. so there will be no memory leaks caused by your struct.
|
|
|
|
|
Thank you all. But what it would be if I use an CString variable instead of LPSTR lpszString ? It would more easy ?
|
|
|
|
|
Yes, if your internal variable is of type CString, then, assigning another CString value to it (or even a LPCTSTR) will automatically do the copying of the string for you, and you don't need to take extra care for releasing it either. That is what string classes are good for.
|
|
|
|
|
I searched for hours, but everything was C# or C++ mfc.
I created a button, using CreateWindow, I found it on a tutorial site on how to make window controls, but there no example on how to handle the click.
So I wrote this, am I missing something like a SendMessage to register the button?
HWND bt_IIS_Install;
bt_IIS_Exit = CreateWindow(L"button", L"Exit", WS_CHILD,
winWidth / 2 - 200,
winHeight - 90,
180, 32, h_IIS_Install_Client, NULL, GetModuleHandle(NULL), 0
);
ShowWindow( bt_IIS_Exit, SW_SHOW);
I found this, that handles a dialog response, so I'm guessing that this is how I capture the button clicks, but I need to assign the defintion to the button.
case WM_COMMAND:
if (LOWORD(wParam) == IDOK || LOWORD(wParam) == IDCANCEL)
{
}
break;
Am I on the right track here?
|
|
|
|
|
You should use the hMenu parameter to specify the control id of your button (IDOK or IDCANCEL in your case)
From MSDN:
hMenu [in, optional]
A handle to a menu, or specifies a child-window identifier depending on the window style. For an overlapped or pop-up window, hMenu identifies the menu to be used with the window; it can be NULL if the class menu is to be used. For a child window, hMenu specifies the child-window identifier, an integer value used by a dialog box control to notify its parent about events. The application determines the child-window identifier; it must be unique for all child windows with the same parent window.
|
|
|
|
|
Thanks for the quick response, who works on Sunday.
I understand, I just need to turn the gears awhile to produce something that works.
|
|
|
|
|
Well that took awhile to figure out. I created a menu in my resource file, and assigned the number to it in the other resource file. Then added the single hMenu item to the create window so WM_COMMAND can pick it up as the wParam. Thanks for the pointer to the huge lesson that I really learned from.
HWND bt_IIS_Install;
bt_IIS_Exit = CreateWindow(L"BUTTON", L"Exit", WS_CHILD,
winWidth / 2 - 200,
winHeight - 90,
180, 32, hIIS_Install, (HMENU)IDC_IIS_WS_EXIT, GetModuleHandle(NULL), 0
);
ShowWindow( bt_IIS_Exit, SW_SHOW);
|
|
|
|
|
I did this in one of my articles - Mousey! Roll Over and Park[^]
The settings dialog and all its controls are created using CreateWindow.
|
|
|
|
|
Great article. So does that mean that I created my buttons correctly?
Writing an app in c++ has been my goal for a long time. Finally had a reason to pursue the next step. I don't want to put anymore visual basic programs out there any more, too much trouble to package and deploy them. I've got this nice eCommerce program, but I can't anybody to use it because it's not super easy to setup and deploy. So this program will make it easier to start using it. The goal is to use a windows program install the web server, create the default web site, import database, create email templates and so forth.
Thanks for looking at my post!
jkirkerx
|
|
|
|
|
I deleted and rebuild both CLW and NCB files.
After rebuild , I have CLW but no NCB file and still cannot add variable in Class wizard.
Added manually and get run time error when variable is used.
This is common and usually works, but not this time.
What did I missed?
Please no "upgrade to X " suggestions.
Any constructive help will be appreciated.
Vaclav
|
|
|
|
|
Found it - Class Wizard disables the add because the class in not checked out in Source Safe.
But it is stupid enough not to say anything about it.
So much for products compatibility.
Thanks MS.
|
|
|
|
|
In the VS IDE (C/C++ Optimization), I usually set these optimizations for Release builds:
Optimization: Maximize Speed (/O2)
Inline Function Expansion: Any suitable (/Ob2)
Enable Intrinsic Functions: Yes (/Oi)
Favor Size or Speed: Favor Fast Code (/Ot)
Omit Frame Pointers: No
Enable Fiber-safe Optimizations: No
Whole Program Optimization: No
What settings do you use?
Has anyone had any good/bad experiences with these settings?
Have you found any helpful blogs as to which settings to use?
|
|
|
|
|
Hans Dietrich wrote: Whole Program Optimization: No
Why do you have this option set to "No"?
Steve
|
|
|
|
|
Mainly due to personal experience. I was trying to track down an intermittent crash that seemingly moved from one area of the app to another. A co-worker suggested removing /GL because it had caused him a similar problem. At this point I was grabbing for anything, so I removed /GL, and that was the last I saw of that crash. I wish I had a better justification, but I don't. There didn't seem to be any noticeable speed slowdown when /GL was removed, so I didn't pursue it.
|
|
|
|
|
I would suggest you save the PDB files generated by the compiler and also save the crash dump after the crash.
You could then debug and get to the root cause of the crash.
|
|
|
|
|
In the kernel I like to turn them all off. That way you get exactly the code you wanted. I have had optimisations take out bits of code I intended to be in their (particulary dead loop timing stuff. Yes, the windows timer has NOT got a low enough granularity. 
You have to write tight code, no function calls in conditions in loops for example, but another benefit is that release code looks like your source, so it is easier to debug release build bugs.
==============================
Nothing to say.
|
|
|
|
|
Optimization: Minimize Size
Inline Function Expansion: Only those explicitly marked
Enable Intrinsic Functions: Yes
Favor Size or Speed: Favor small code
Omit Frame Pointers: No
Enable Fiber-safe Optimizations: Yes
Whole Program Optimization: Yes
Favour size or speed is a result of previous issues with speed optimizations causing problems. Also, smaller code can result in less page swapping, which swamps any benefits from 'faster' code.
I had also done a compare of a number of apps compiled both ways. I was rarely able to find significant differences in speed, but often in size - the size opt had more effect.
Inline expansion 'Any' has caused significant module bloating for me before. This usually happens with template code. I like this part to be deterministic.
Fiber/whole optimizations, never had a reason to turn them off.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
cmk wrote: the size opt had more effect
I assume you mean the size opt yielded faster speed than the speed opt?
cmk wrote: smaller code can result in less page swapping, which swamps any benefits from 'faster' code.
What was the exe size in this case?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
