|
just go to the resource file , you see the menu items. change then name there. recompile and run
If u can Dream... U can do it
|
|
|
|
|
SetMenuItemInfo[^] allows you to change a menu item by handle. This would be useful if you don't have access to the resource file or if you want to use an if/else block to decide how to change the menu.
modified 13-Sep-18 21:01pm.
|
|
|
|
|
In Win32 C++ how to convert
TCHAR* to LPCTSTR
TCHAR to LPTSTR
Please help...
gold
|
|
|
|
|
|
What do you mean by convert?
TCHAR* is merely a pointer to a char or wchar_t depending on the definition of UNICODE . LPCTSTR is a typedef to const TCHAR* so no conversion is necessary; but you may need a cast to satisfy the compiler.
TCHAR is a single character so cannot be converted or cast to LPTSTR ; if you actually meant TCHAR* then both expressions evaluate to the same thing: a pointer to a character or wide character.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
Thanx, my one doubt is cleared, about TCHAR to LPTSTR
My Program deals with UNICODE only
a small example will very helpfull for me, of how to convert TCHAR* to LPCTSTR and LPTSTR.
Thanx in advance.
gold
|
|
|
|
|
goldenrose9 wrote: a small example will very helpfull for me, of how to convert TCHAR* to LPCTSTR and LPTSTR.
There is no conversion involved; as I said in my previous post TCHAR* and LPTSTR equate to the same thing, a pointer to a string (character array). LPCTSTR is the same as const TCHAR* , a pointer to a string constant.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
TCHAR* to LPCTSTR is a simple typecast
TCHAR* pch;
LPCTSTR pcch = (LPCTSTR)pch; TCHAR to LPTSTR is an address of operator
TCHAR ch;
LPTSTR pch = &ch;
|
|
|
|
|
LPTSTR __stdcall gHelp(TCHAR value)
{
LPTSTR pch;
pch = &value;
return pch;
}
compiler gives warning
warning C4090: 'return' : different 'const' qualifiers
gold
|
|
|
|
|
You will also have a problem that you are returning a TCHAR* to a TCHAR value, not an array (i.e. string). Do not do this or you will end up with memory overwrites and/or invalid data.
As to your compiler warning, you must have a definition of gHelp which reads something like:
LPCTSTR __stdcall gHelp(TCHAR value);
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
This won't work. You are passing the TCHAR variable by value, so the parameter value is just a temporary local copy, and the address of it will be invalidated upon return! Pass the TCHAR parameter by reference instead, like this:
LPTSTR __stdcall gHelp(TCHAR& value)
...
|
|
|
|
|
Here[^] is an excellent article explaining everything you need to understand C++ strings.
|
|
|
|
|
goldenrose9 wrote: TCHAR* to LPCTSTR
Usually, no conversion needed. If a function is promising you that it won't modify the contents (thereby expecting an LPCTSTR ), you can still pass on a normal TCHAR* to it.
goldenrose9 wrote: TCHAR to LPTSTR
That makes absolutely no sense. TCHAR is a character (wide or not depends on the build), and LPTSTR is a pointer to one such character. How can you convert one to another?!
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|
|
|
Hi, I'm beginner....
I have a question about MFC...
Fist of all, I make the project, SDI...
and I divided View window with CSplitterWnd in MainFrm...
1 Row, 2 Cols...
and I pasted left windows my basic view window...
and I make a new View class deserved CView.
this point....
I want to know a View class to a Variable....
ex) I do that..
CSecondView* m_Second;
m_Second = new CSecondView;
m_wndSplitter.CreateView(0, 1, RUNTIME_CLASS(m_Second), CSize(cr.Width(), cr.Height()), pContext);
but this is error...
I don't know what wrong is ??
|
|
|
|
|
replace this :-
CSecondView* m_Second;
m_Second = new CSecondView;
m_wndSplitter.CreateView(0, 1, RUNTIME_CLASS(m_Second), CSize(cr.Width(), cr.Height()), pContext); with this :-
m_wndSplitter.CreateView(0, 1, RUNTIME_CLASS(CSecondView), CSize(cr.Width(), cr.Height()), pContext); you might want to read this MSDN[^] article on CSplitterWnd for more information.
|
|
|
|
|
Hi,
I am creating a file using CreateFile().
My machine is having symantec anti virus, when I done with CreateFile and closes the file handle I gets warning box from symantec
"Scan type: Auto-Protect Scan
Event: Security Risk Found!
Security risk detected: Bloodhound.Exploit.274
...................................
..................................."
How can I avoid that?
code is :
HANDLE hFile = CreateFile(szFilePath,GENERIC_READ|GENERIC_WRITE,NULL,NULL,CREATE_ALWAYS,NULL,NULL);
|
|
|
|
|
You can change your anti-virus settings to ignore a particular path or file, and possibly digitally sign your file. However, I am very surprised that CreateFile causes a problem. I think I've used Symantec with CreateFile before without any issues and without needing to specify that it should not scan the exe.
|
|
|
|
|
Is there anything special about the file's name or its contents?
"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
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
See this[^]. You might send one of your files to Symantec as a sample of missidentified file.
|
|
|
|
|
The content that you write in the file probably match the signature of the virus.
|
|
|
|
|
Symantec is not new in making "strange things".
Look at this[^]
It seems even an empty WinMain is a virus!
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
I think that this isn't a major problem.
As per their docs, they identify something as a bloodhound exploit 274 if there's a piece of potentially malicious code that attempts to exploit the integer overflow vulnerability in GDI+. Symantec themself say that even an innocent program could be identified as malicious due to the "sensitive" nature of the detection technology used for identifying this particular malware (in cases where your program somehow share the behavioural characteristics of the code that exploits the said vulnerability).
Apply the patches if that's not already done, and if the problem persists, send your program to Symantec as what's being wrongly detected as malware.
Bloodhound Exploit 274[^]
Microsoft security bulletin article on the topic.[^]
And with all seriousness, I do hope that you're not writing code that exploits the vulnerability.
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|
|
Rajesh R Subramanian wrote: As per their docs, they identify something as a bloodhound exploit 274 if there's a piece of potentially malicious code that attempts to exploit the integer overflow vulnerability in GDI+.
Humm ... What does it have to do with "CreateFile"?
Rajesh R Subramanian wrote: Symantec themself say that even an innocent program could be identified as malicious due to the "sensitive" nature of the detection technology used for identifying this particular malware
Buzzshit and Bullwords. They have a bug and are trying to sell it as a feature. Not a good behavior for a commercial company.
Rajesh R Subramanian wrote: Apply the patches if that's not already done, and if the problem persists, send your program to Symantec as what's being wrongly detected as malware.
int WinMain(HINSTANCE, HINSTANCE, char*, int)
{ return 0; }
We're still wating aswer s from them!
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Emilio Garavaglia wrote: Humm ... What does it have to do with "CreateFile"?
If he's writing binary data into a file, and if the buffer pattern matches with what they think could be malicious, then they'd want to stop it.
Emilio Garavaglia wrote: Buzzshit and Bullwords. They have a bug and are trying to sell it as a feature. Not a good behavior for a commercial company.
Yeah, I kinda agree. I thought what the hell could be sensitive (you see, I marked that in double quotes in my previous response).
Emilio Garavaglia wrote: We're still wating aswer s from them!
You didn't receive a response from them doesn't mean the OP shouldn't submit his case.
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|