|
Did you set it before "$(VCInstallDir)PlatformSDK\include"?
|
|
|
|
|
Where and how can I set it?
|
|
|
|
|
Set "C:\Program Files\Microsoft SDKs\Windows\v6.0\Include" before "$(VCInstallDir)PlatformSDK\include".
|
|
|
|
|
Hi all,
I want to count number of words depend on the space character. That means I want to tokernize a string. How can I do that. I'm looking at the strtok() function. But I can't use char* there in the following code.
int word()<br />
{<br />
char *token;<br />
std::string str = "This is a line of text";<br />
<br />
token = strtok(str, " ");<br />
do<br />
{<br />
printf("token: %s\n", token);<br />
}<br />
while (token = strtok(NULL, " "));<br />
}
Can somebody help me to do this.
Thanks
I appreciate your help all the time...
CodingLover
|
|
|
|
|
Have you tried using CStringT::Tokenize ?
|
|
|
|
|
Ah, actually I just want to use standard C++ only. Not with MFC pal. Reason is that until now whole my application develop on without C++ and I want to keep it as it is.
I appreciate your help all the time...
CodingLover
|
|
|
|
|
If you want to stick to C++, then better use std::stringstream . Check this link[^] about how to split strings using stringstream .
Regards,
Jijo.
_____________________________________________________
http://weseetips.com[ ^] Visual C++ tips and tricks. Updated daily.
|
|
|
|
|
The function isspace will help you in this case. Loop through & check character by character. If you encounter a space, increment the count..
Regards,
Rane
|
|
|
|
|
CodingLover wrote: Ah, actually I just want to use standard C++ only. Not with MFC pal. Reason is that until now whole my application develop on without C++ and I want to keep it as it is.
???????????????????????????
Bram van Kampen
|
|
|
|
|
CodingLover wrote: my application develop on without C++
???????
|
|
|
|
|
Hi,
Why not go back to basics, read chars one by one, and use isspace(x)
About three nested loops will do the trick, and you can debug it yourself.
You then do not need to spend hours scouring the Internet for obscure specifications, and even more hours studying same.
I know the performance argument. Unless if you have gazillions of data to sift thru, I personally have found that issue largely accademic.
Regards
Bram van Kampen
|
|
|
|
|
Hi,
I have a Dialog Based App, which requires different menu's in the Main Dialog depending on a situation investigated during InitInstance(). dlg.m_nMode is set by InitInstance();
CMenu * pMenu=GetMenu();
pMenu->Detach();
switch(m_nMode){
case MODE_NOT_STARTED:
ASSERT(0);//Should Never Happen
exit(0);
break;
case MODE_MASTER:
pMenu->LoadMenu(IDR_MENU_MASTER);
SetMenu(pMenu);
SetStatusText("Running Process...");
break;
case MODE_SLAVE:
pMenu->LoadMenu(IDR_MENU_SLAVE);
SetMenu(pMenu);
SetStatusText("Monitoring Process...");
break;
}
All behaves as expected, except that on rare occasions I get an exception when closing down relating to the unwinding of the handle map.
Bram van Kampen
|
|
|
|
|
Bram van Kampen wrote: CMenu * pMenu=GetMenu();
pMenu->Detach();
.
.
pMenu->LoadMenu(IDR_MENU_MASTER);
I think the problem is because of using the pointer returned by GetMenu() function. Such pointers are actually temporary objects and will be destroyed in while process is Idle.
So instead of
CMenu * pMenu=GetMenu();<br />
pMenu->Detach();
try
CMenu * pMenu= new CMenu();
And dont forget to delete the pointer after use.
|
|
|
|
|
Well, that's how I Started. If I do not use pMenu->Detach() I get other Runtime Errors. Also, the temporary nature of some pointers manifest itself between framework calls. The Only thread is running in My Module, so there is nothing that can (or should be able to)change things between the lines of code in the one function. In Short: The thread does Not do OnIdle() between the Lines of a function I wrote, It may only do so after I leave a Framework Call.
Thanks,
Bram van Kampen
modified on Monday, September 1, 2008 9:52 PM
|
|
|
|
|
Did you remove previous menu before load new menu?
|
|
|
|
|
CMenu * pMenu=GetMenu();
pMenu->Detach();
What else should or could I do?
regards
Bram van Kampen
|
|
|
|
|
And did you use of DestroyMenu?
Of MSDN: The DestroyMenu function destroys the specified menu and frees any memory that the menu occupies.
|
|
|
|
|
Sorry for the Dalay,
Hamid. wrote: And did you use of DestroyMenu?
No, I Did not, and that solved it.
Thanks.
Bram van Kampen
|
|
|
|
|
And vice versa Im very fast.
|
|
|
|
|
Hi,
I have a DOS console application which sends a lot of data to STDOUT
I would like to make it more readable Create a WIN32 GUI to Display
the information maybe in a EditBox
I Statred by Doing a CreateProcess to Create the WIN32 app
My question What is the best way of Communcating the Data Between
The Dos Console process and the Win32 GUI process
I have done some reading and it seems Anoymous pipes are best suited
for what I have in mind
Any comments
Greatly appreciated
|
|
|
|
|
Well, you have One App running as a Console Process. To pipe the Output to a gui, you need a gui in another app that monitors your Console Process as a Debugger. Matt Pietreck wrote a lot about this, and it is a way of doing things.
The quickest and easiesr way is I think, to start a New Windows GUI based App, (Probably Dialog Based, give it a main() global function which calls your App, and write a number of Macro's which convert the stdout calls to writing to an edit box in your Main Dlg.
BTW Have you ever thought of piping your output to a file, and then reading it with say Notepad.
Console Programs and GUI programs have entirely different design phylosophies as underlay, and cannot be readily converted from one into the other.
Bram van Kampen
|
|
|
|
|
If I am to understand your suggestion re: writting macros to convert STDOUt calls to Dialog base writes e.g Writting to an EditBox Dialog
Would I stil have tso apps Dos Win GUI
re: writting the Dos to GUI would be a huge Task
|
|
|
|
|
No,Only One Program. You would have converted your App to a Windows App. (Remember QWindows in the Win 3.1 days?) I Don't know what your app does. Do you want to do this purely for Debugging, or is it something that in this day and age deserves a GUI. If it is just debugging, I'd pipe the output to a Text File, and get on with it. Otherwise, it may be time to consider a Root and Branch re-design. The reason for this is that your 'DOS' program is not designed to act on 'Mouse Clicks'. The ability to do so introduces a fundamentally different design to the program structure.
ForNow wrote: writting the Dos to GUI would be a huge Task
Well, that may be so, but it also depends on the Code you have.
Time Moves on, and the Next OS is unlikely to be Console Based. If the App is of any importance at all, it may Pay to Convert.
The 'Working Parts' i.e. That part of the Code that solves the actual Problems will often be much the same. A Lot of the Formatting Code which goes into a Console Program (Reading Input,Validation,GoBackIfNotValid, Writing Output)will fall into categories: A Lot Easier in Windows, Salvage Elements, Derelict(No Windows Equivalent, Mostly Not Needed)
A lot of the Control Structures (if it's this goto there) will be taken over by the GUI Interface.
The way I approached this in the past was by first designing a User Interface based on how a User would approach the problem the Console Program is supposed to solve. (Important: Forget about how the Console Program Approached this). Get Dialogs for All required Data, and introduce the 'Workhorses'of the Console App One by One.
All I can say is: Been there, Done that, Got the Teeshirt to Prove.
Regards
Bram van Kampen
|
|
|
|
|
Okay I'll let the cat out of the Bag
I'm talking about Hercules The MainFrame Emulator
As a MainFrame Programmer I want to take this oppurtunity to learn
Windows Programming
|
|
|
|
|
I Suggest that you first learn how to program for windows per se, preferably on a PC running Windows. As you are addressing a CPP/MFC forum I assume that you would want to use MFC. (You can also do it in CPP, without MFC, but that means using SDK, which is harder again, and vastly more labour intensive) I sugest you start with the 'MFC-Scribble' tutorial. It gives you an idea how windows works under MFC. Converting a Console Program into windows is vastly more complicated than writing a simple windows program from scratch. You will have to understand and appreciate the event driven nature of code written for windows, before you can start to disect and re-write existing console code.
Regards,
Bram van Kampen
|
|
|
|