|
I think you're on your own.
Suggestions:
1) Open the file and read first 1-2K and check for ASCII < 20 and ASCII > 127. (By far the simplest.)
2) Open the file and read first 1-2K and look for SPACES and puntuation (,.!?'";). I would expect the length of words on average to be pretty small (<20 letters).
3) Open the file, check first 1-2K for words in a dictionary. If most words found are not in the dictionary, it's probably binary.
|
|
|
|
|
10x for the excellent ideas
R.
|
|
|
|
|
Open the file. Read the first 1024 bytes. You can bet yourself that if it's a binary file there will be a few bytes within the first 1024 that are not alphanumeric or punctuation.
Nish
p.s. If you have UNICODE text files you have a problem though 
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Buy it, read it and admire me
|
|
|
|
|
We are facing a problem of :
We call a VC++ exe (Form View single document application) from C#
But we want to close it after it’s execute
We tried after
WaitForProcess
Process.CloseMainWindow
&
Process.Close
|
|
|
|
|
The following C++ code waits for the app to terminate before continuing. It may be of some help
HANDLE hProcess = NULL;
SHELLEXECUTEINFO shellInfo;
::ZeroMemory(&shellInfo, sizeof(shellInfo));
shellInfo.cbSize = sizeof(shellInfo);
shellInfo.fMask = SEE_MASK_NOCLOSEPROCESS;
shellInfo.nShow = SW_HIDE;
shellInfo.lpFile = _T("anyapp.exe");
shellInfo.lpParameters = args;
if(::ShellExecuteEx(&shellInfo))
{
hProcess = shellInfo.hProcess;
if (hProcess != NULL)
{
::WaitForSingleObject(hProcess, INFINITE);
::CloseHandle(hProcess);
}
}
|
|
|
|
|
|
I am displaying a modeless dialog in my app...everything related to the dialog works fine. However, there is a button in the Windows taskbar with no text displayed and it is associated with the modeless dialog.
How do I get the button not to appear in the taskbar when the modeless dialog is launched?
|
|
|
|
|
There is an article here on CP that Chris Maunder wrote.
And Mike Dunn: This question should be in the FAQ!
Rickard Andersson@Suza Computing
C# and C++ programmer from SWEDEN!
UIN: 50302279
E-Mail: nikado@pc.nu
Speciality: I love C# and C++!
|
|
|
|
|
Read :-
http://www.codeproject.com/useritems/dlgboxtricks.asp
There is a tip there called "Removing the task bar icon of your dialog based App"
Use the same technique mentioned there.
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Buy it, read it and admire me
|
|
|
|
|
Thanks for the reply. I found an easier way (in a reply to an article)...just set the dialog style to Tool Window. Now I have another problem to work through...I want the modeless dialog window to always be on top, so I made it the topmost window...works fine. I want to keep it from grabbing the focus every time I move or resize the MDI Mainframe window... the mainframe window is the dialog's parent.
Any Ideas?
Also, the dialog remains on top when I switch to other applications like Word or Excel...Does anyone now how to stop this behavior?
|
|
|
|
|
if you make the desktop the parent of the dialog (ie. use NULL as the parent), it will be completely independent of the application's focus.
-c
Cheap Oil. It's worth it!
|
|
|
|
|
I tried what you suggested...It made no difference...The modeless dialog still grabs focus when I resize the mainframe window and it is still in front of other, non application, windows when when I switch to other applications
|
|
|
|
|
Let's say you are using MFC, and have a function that accepts a constant string as its argument. Which is better style:
1. int SomeFunction(LPCTSTR stringArgument);
2. int SomeFunction(const CString &stringArgument);
Most MFC functions use a form of number 1, but it seems number 2 is more "object oriented", at least by appearance. I guess number 2 would have to create a CString object on the fly if you specifiy a constant string, so there may be a performance difference..?
Or am I just being anal and it doesn't make that much of a difference in real life? 
No generalization is 100% true.
Not even this one.
|
|
|
|
|
/me eagerly waits others opinions..
i'd say number 2, because i hate 'LPCTSTR', i do my best to avoid that damn keyword .. prolly cause im scured..
-dz
|
|
|
|
|
dazinith wrote:
i'd say number 2, because i hate 'LPCTSTR', i do my best to avoid that damn keyword .. prolly cause im scured..
Yeah I know what you mean, Windows and it's butt-ugly keywords. But it is nice to have something that'll work with Unicode, multi-byte, and ANSI builds.. otherwise I'd just good old const char *.
No generalization is 100% true.
Not even this one.
|
|
|
|
|
const CString& sParam.
There is a good aricle in MSJ now MSDN magazine around '95/'95 which describe the best method calls with LPSTR/LPCSTR/CString/CString& I think the article could be by Jeff Process/Jeff Richter or even Paul De Loucia - sorry Paul if I spelt your name wrong.
Normski. - Professional Windows Programmer
|
|
|
|
|
Soudns all right, but won't that create a temporary CString object to pass into the function? Of course, that may be such a small overhead that nobody will ever notice..  
No generalization is 100% true.
Not even this one.
|
|
|
|
|
Navin wrote:
won't that create a temporary CString object
yes, it will.
but, it will probably be no big deal (unless it's in a loop or you're passing GB strings, etc.)
-c
Beware the leader who bangs the drums of war to whip the public into patriotic fervor, for patriotism is a double-edged sword. It emboldens the blood and narrows the mind. When the drums of war have reached a fever pitch, the blood boils and the mind closed, the leader will not need to seize the rights of citizens. Rather, infused with fear and blinded by patriotism, they will gladly offer up their rights. How do I know? For this is what I have done. And I am Caesar.
|
|
|
|
|
Chris Losinger wrote:
yes, it will.
What? Really? Even if he's passing by reference? 
--------
Hey you Whitehouse, ha ha, charade you are
You house proud town mouse, ha ha, charade you are -- Pink Floyd, Pigs (Three Different Ones)
|
|
|
|
|
you can't pass a char * as a CString - they ain't the same thing.
try it.
-c
Cheap Oil. It's worth it!
|
|
|
|
|
*slaps self*
Sorry, didn't read the question correctly. Thought he was passing a CString as the parameter 
--------
Hey you Whitehouse, ha ha, charade you are
You house proud town mouse, ha ha, charade you are -- Pink Floyd, Pigs (Three Different Ones)
|
|
|
|
|
I use number one exept no unicode support and i don't use LPTSTR, i don't like it.
const char *stringArgument
LPCTSTR = A 32-bit pointer to a constant character string that is portable for Unicode and DBCS.
|
|
|
|
|
I never use LPTSTR. I may have a TCHAR array here and there if I need to pass a non-const string to a system API. But I never use functions that take LPTSTR - I'd use a non-const reference to a CString in that case.
For clarification, what I meant about a parameter creating a temporary CString object is in this scenario. I guess it would only matter, as Chris Losinger said, if you pass in great big strings or are in a loop or something like that.
void SomeFunc(const CString &![Green Alien | [Alien]](https://codeproject.freetls.fastly.net/script/Forums/Images/alien.gif) )
{
...
}
...
// This will create a temporary CString to pass into
// SomeFunc.
SomeFunc("This is not a C-String!");
// But this won't.
CString = "This one is.";
SomeFunc( );
Yes, I know it is against C++ standards to use an icon as a variable name. 
No generalization is 100% true.
Not even this one.
|
|
|
|
|
You have to look at what you are doing with your string. What is coming in and how it will be used inside the routine.
Outside routine: CString
Inside routine: CString (for example, storing into a local str var)
Argument: const CString &
In this case, you are able to take advantage of the reference counting used by CString. No duplicate strings will be created. (GOOD)
Outside routine: CString
Inside routine: CString (for example, storing into a local str var)
Argument: LPCTSTR
In this case, the CString will just pass the pointer to the internal string. However, once that string is used as a CString inside of the routine, a duplicate will have to be made. (BAD)
Outside routine: LPCTSTR
Inside routine: CString (for example, storing into a local str var)
Argument: const CString &
In this case, a CString will have to be created prior to the routine being invoked. However, since the routine will actually be using the CString internally, it would have had to have been created anyway. No performance loss. (GOOD)
Outside routine: LPCTSTR
Inside routine: CString (for example, storing into a local str var)
Argument: LPCTSTR
In this case, the string is being passed directly into the routine. Then internally a CString is being created. However, the same would have been true if the argument was CString. (GOOD)
Outside routine: CString
Inside routine: LPCTSTR (maybe a call to _tcscmp)
Argument: const CString &
In this case, the string is passed directly in and the routine just uses the (LPCTSTR) operator in CString to access the contents. No performance loss. (GOOD)
Outside routine: CString
Inside routine: LPCTSTR (maybe a call to _tcscmp)
Argument: LPCTSTR
In this case, the CString will just pass the pointer to the internal string. The routine will use the pointer as is. (GOOD)
Outside routine: LPCTSTR
Inside routine: LPCTSTR (maybe a call to _tcscmp)
Argument: const CString &
In this case, a copy of the string will get created to be passed as a CString. Then the CString is just dereferneced. Needless creation of temp string. (BAD)
Outside routine: LPCTSTR
Inside routine: LPCTSTR (maybe a call to _tcscmp)
Argument: LPCTSTR
In this case, the string is being used as is. No temp objects. (GOOD)
SOOOOOOO
If you total it all up:
Case 1:
If inside the routine you are using the string as a CString:
Argument as CString: 2 good cases, no bad.
Argument as LPCTSTR: 1 good case, 1 bad case.
So, when the routine will be using the string as a CString, there is no reason to not use "const CString &" for the argument.
Case 2:
If inside the routine you are using the string as a LPCTSTR:
Argument as CString: 1 good case, 1 bad case.
Arguemnt as LPCTSTR: 2 good cases, no bad cases.
So, when the routine will be using the string as a LPCTSTR, there is no reason to not use "LPCTSTR".
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
I have a program Visual C++ which is connecting to SQL 2000. Because the SQL 2000 set to WindowsNT authorization I can't use the 'sa'. How do I deal with this problem??
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
