|
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
|
|
|
|
|
|
I have five methods:
1、name pipe
2、share file
3、process message
4、socket message
5、paste clipe board
and I think the process message may be the best suited.
【成功就是在跌倒之后还能爬起来...】
|
|
|
|
|
|
Ok, I know how I got into this mess generally, but I need to understand the mechanics to avoid it in the future. I have a rather large project that makes use of numerous custom activeX controls. Adding some new functionality to one of the activeX controls, while at the same time other developers modifying dialogs, I've blundered into
"Control <xxx> could not reload its state from its data saved from the last time the dialog editor was used.
The control will be uninitialized on the dialog."
If I go back to the old control, it still gives me the same error. So, I'm toast, and I'll have to fix the locations where I've used this control, once I complete my code modifications.
But, what exactly did I do that caused the issue? My guess is that I added some properties, and since they don't
exist in the saved rc file, the dialog editor won't load them. I've added methods before and not had this problem.
Which raises another question - how would one version the control so that I could migrate settings from one control
version to another, or perhaps default values such that the new properties migrated gracefully.
Charlie Gilley
Will program for food...
<italic>Hurtling toward a government of the stupid, by the stupid, for the stupid we go. —Michelle Malkin
|
|
|
|
|
Well if anyone ever does this to themselves, I figured out the problem.
First, never ever delete a property from an activeX control (assuming the control is in use). This breaks the contract with the saved data, making it impossible to ever load.
Second, you have to handle versioning of serialized data that is saved/restored in the resource file (handled by the control magic). It's all explained in the last couple of pages of chapter 15 in Professional MFC.
You just have to read the entire chapter.
Charlie Gilley
Will program for food...
<italic>Hurtling toward a government of the stupid, by the stupid, for the stupid we go. —Michelle Malkin
|
|
|
|
|
Hello. Perhaps someone out there can help me with a small but annoying problem that is threatening my mental health. One of my clients wants to use legal paper in an application that I sold him. I've set the printer to legal and have put legal paper in it ( Both of us use HP printers ) but every time the Printer dialog comes up and I go to Properties/Layout/Advanced it's set to letter. For me it's annoying to have to set the page size there every time. For my users it's a bridge too far. Does anyone out there know what C++ class/structure holds that info and how I can be assured that it's set to Legal? Thank you.
|
|
|
|
|
Take a look at the DEVMODE structure (documentation here) - there are settings regarding paper size there; take a look at the dmPaperSize member in particular.
This structure can then be passed as a parameter of the PRINTDLG or PRINTDLGEX structures which are passed as a parameter for the print dialog box.
Regards,
--Perspx
"The Blue Screen of Death, also known as The Blue Screen of Doom, the "Blue Screen of Fun", "Phatul Exception: The WRECKening" and "Windows Vista", is a multi award-winning game first developed in 1995 by Microsoft" - Uncyclopedia
Introduction to Object-Oriented JavaScript
|
|
|
|
|
Thanks. I'll check into it today. It's annoying to have to spend valuable programming time on stuff like this but it's critical to my customers. BTW, I saw that you're a guitar player. I've been playing for about 30 years and play out once or twice a month here in NYC. It's amazing how many programmer/musicians are out there. I tell my 10 year old son (who's also a guitar player) that they're complimentary skills.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
