|
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
|
|
|
|
|
Not being a C++ programmer a plains old WIN32 GUI seems to be a pretty big undertaking
I understand that unammed pipes were meant WIN32 gui parent and a DOS Console Child process
not the other way around as WIN32 GUI doesn't have stdin/stdout
That being the case would named piped or Windows sockets work for me having a parent dos console process and a win32
gui child ....if so which is better
thankx
|
|
|
|
|
ForNow wrote: Not being a C++ programmer a plains old WIN32 GUI seems to be a pretty big undertaking
Windows Programs can be written in any language, Machine Code, Asm C, CPP, etc.
Windows is a proprietary Microsoft product, and for it to work, you need the Windows OS on the target Computer.
Microsoft also wrote a large amount of re-distributible library code, which you buy rights to when you buy their compiler. This Library code unifies the Windows User Interface across the world.
You are free to write your own UI in whatever language you choose, but, you are then trying to replicate what was debugged over millions of hours on the microsoft campus.
ForNow wrote: I understand that unammed pipes were meant WIN32 gui parent and a DOS Console Child process
not the other way around as WIN32 GUI doesn't have stdin/stdout
You misunderstand this. Pipes are a structured method of communication between windows processes. Although the original idea came from the Unix Pipes, the Idea has advanced since. Windows is not aware of a thing like a console process, but uses the Pipe mechanism to implement it.
ForNow wrote: That being the case would named piped or Windows sockets work for me having a parent dos console process and a win32
The way a DOS program is written, (i.e. Procedural, that means, You write code to ask the user a question, you evaluate the result, ande you decide where to go from there) is a totally different type of program design.
In a Windows program, you react to the user clicking in or on something,
anything at all, and, if you want something specific to happen when they click, you write a piece of code to deal with that event.It is at User level, Not sequential If the User clicks OK, that does not mean that all required entries have been made, that is for you to check (if you use the Micrisoft MFC Library) in the OnOK Handler( the function called when the user clicks on 'OK') If you go for ASM, you've to write this behaviour yourself
Hope this helps
Bram van Kampen
|
|
|
|
|
Hi,
I did some reading and I came up with a plan
My First assumption in a DOS console program is there anything that
that I cann't use the SDK library calls... Well I obviously cann't do a Create Window
However I would think I could do API's like CreateNamepipe
or SendMessage So Here goes
in My DOS console program I will try CreateNamePipe
to commuicate I will use the Ex Versions Of ReadFile and Write FIle
In The case of The Write File in The Dos Program and The I/O is comp
and CallBack Function Gets control I will try to Do a SendMessage
With WM_COPYDATA this should notify The WinDows GUI that data is out
there
When the WinGUI wants data and Issues WriteFileEx
Can CallBack Function Be A EXported function in the Dos program
Not to Sure About this ???
What do think ?????
|
|
|
|
|
Well,
The Proof is in the Compiling and Debugging
Try it, it may work, or, maybe not!
ForNow wrote: Can CallBack Function Be A EXported function in the Dos program
Yes, ofcourse it can in principle. Just be aware of the general DLLHELL issues, Calling conventions, Thread Locks, and the Name Manglin Feature incident to the various compilers. As a mainframe computer expert you are undoubtedly aware of these minor issues. Apart from that it should be plain sailing.
Regards  
Bram van Kampen
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
