|
On the handler of the first button you can set a global variable (declared in theApp or inside the class where you are working (possibly the same dialog)) to true, and then once you press the second button you can check the state of that variable. Of course you should revert the state of that variable to false once the compiler has finished it's work...
Somehow I have a feeling that the question (how to know if you have pressed a button) and the job done (a compiler) are no matching very well...
|
|
|
|
|
I am using one boolean variable(Initially it is false). In the code of second button i am initializing this variable to true. In the first button code, after finishing every phase(i.e, after compilation, linking and execution) i am checking whether this boolean variable is true or false. If this boolean variable is true then i am returning the control(return statement).
Now the problem is when my application is executing the code behind the first button i am unable to click the second button.
what code i should write for clicking the second button, when first button is performing its operation ???
Thanks in advance
Sanjeeva Kumar.
|
|
|
|
|
Sanjeeva Kumar K wrote: when my application is executing the code behind the first button i am unable to click the second button.
Haven't you read on multiple threads and synchronization techniques? If not, probably it's time to read on those topics. And I think you're going too far without knowing the basics.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
I suppose that what is happening here is that you should be using a multi threaded application to do that... if your main thread gets blocked because you are processing the compilation... then the program won't answer to anything until it has finished...
You should read about a "worker thread" and the synchronization objects that are available.
Hope this helps...
PS: Are you sure that you have made a compiler?
|
|
|
|
|
Joan Murt wrote: Somehow I have a feeling that the question (how to know if you have pressed a button) and the job done (a compiler) are no matching very well...
If he knows how to program a compiler, he should have known how to do flow-control though. 
Maxwell Chen
|
|
|
|
|
By using GCC compiler i am compiling, linking and executing the 'C' source file.
My application selects a 'C' source file and by using GCC compiler i am compiling, linking and executing it.
|
|
|
|
|
Sanjeeva Kumar K wrote: By using GCC compiler i am compiling, linking and executing the 'C' source file.
My application selects a 'C' source file and by using GCC compiler i am compiling, linking and executing it.
I see. So you are not making a "compiler" per se which parse every token in the sources, but are making a GCC invoker. 
Maxwell Chen
|
|
|
|
|
Normally, when using the Spy++ find window tool, you can mouse over a dialog and the controls will highlight as you mouse over them, allowing you to click them and then have Spy++ select them in its list of windows.
We have a dialog app and this has worked fine for that app. We recently upgraded to a new version of a third party GUI library we use and are seeing some wierdness.
When trying to use Spy++ to examine the windows, I noticed that the Spy++ find window tool no longer works in this dialog. With the find window tool active, when you mouse over the dialog the controls do not highlight. If you move to the title bar the dialog does highlight. If you click the dialog, you can see it in the Spy++ list along with all the child controls.
I guess I'm grasping at straws a bit, but this seemed really unusual. I can run an older version (before the third party GUI library update) and it works fine.
Any ideas what (if anything) this strange Spy++ behavior could indicate?
|
|
|
|
|
Dave Calkins wrote: you can see it in the Spy++ list along with all the child controls
Are you sure the above list contains the controls that Spy++ find window tool cannot detect?
I mean maybe those controls aren't windows.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
yes, they are windows. although they don't highlight when mousing over with the find window tool, if you mouse over the dialog title bar and click it, it finds it in the list. If you then expand the tree, you can see all the controls listed as windows. In the list, you can right-click and highlight them and they do highlight.
It just seemed that the mouse-over behavior was odd and I was wondering if that indicated anything particular.
|
|
|
|
|
I've seen this quite a few times with controls that are obscured by others. I never bothered to find a solution, if there even is one.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Dave Calkins wrote: Any ideas what (if anything) this strange Spy++ behavior could indicate?
yes
Dave Calkins wrote: third party GUI library we use
Therefore
Dave Calkins wrote: seeing some wierdness.
Does this library include source code? If not then you need to be asking them not us. If the library does not include source code then you have eliminated yourself or any other developer from solving the problem. You are now completely at the mercy of the third party. Are you having fun yet?
led mike
|
|
|
|
|
led mike wrote: yes
can you be more specific? 
led mike wrote: Does this library include source code? If not then you need to be asking them not us. If the library does not include source code then you have eliminated yourself or any other developer from solving the problem. You are now completely at the mercy of the third party. Are you having fun yet?
yes, the library includes source code. I have asked them and they're not sure either. Its a strange issue and the Spy++ behavior seemed odd so I thought I'd ask what that could indicate.
The issue is we're using custom control from the library which provides menu toolbar functionality. It uses a menu resource along with toolbar icons and provides icons in the menus, etc. Its worked fine for some time, but upgrading the third party GUI library results in the menu no longer rendering. The toolbar is there, but is empty. None of the menu items render.
Creating an empty sample project works fine. The menu shows as expected using the new vesion of the library. So there's something messed up with the project. I tried Spy++ just to see what was there and saw the strange mouse-over behavior. As I said, there's some straw grasping going on
|
|
|
|
|
Well at least you have the source so you will just have to dig in and figure it out. Menu's can be a quite stubborn. It sounds like perhaps something is not being created successfully so I might start by checking out how they implemented creation. Like are they logging or asserting or throwing or whatever. Since you have source you could add any of those that might be helpful in researching the problem.
led mike
|
|
|
|
|
well, I noticed something else which might provide a hint. If I hit the Alt key and then the down arrow, the drop down menus appear, but they appear as though they're dropping down from under the title bar and each top level menu (accessed by using the right and left arrow keys) shows up in the same place.
I guess I'll dig into their rendering code. Maybe the positioning was somehow hosed.
|
|
|
|
|
Interesting. Are your controls, by chance, contained within other controls?
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Individuality is fine, as long as we do it together - F. Burns
|
|
|
|
|
no, they're direct children of the dialog.
|
|
|
|
|
Hmmm... I don't have that same problem (using the same library). Contained control controls are not showing up and the ones that do, Spy++ says it can't find the window at all. So while I can find the controls, Spy++ still can't find them.
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Individuality is fine, as long as we do it together - F. Burns
|
|
|
|
|
Hello everyone,
I am learning set_se_translator, and there are some good resources about how to translate structured exception into C++ exception, like,
http://www.codeproject.com/KB/cpp/seexception.aspx
1.
What makes me confused is, when we are talking about translate, it means both structured exception and C++ exception may occur in a C++ program, right?
2.
But from build option, we can select either /EHa or /EHsc, means we can only select one type of exception, either asynchronous (structured) or synchronous (C++ exception).
(1) and (2) are conflict?
thanks in advance,
George
|
|
|
|
|
/EHsc enables standard exceptions. It does say nothing about the proprietary form.
Also, MSDN clearly states
"The two exception handling models, synchronous and asynchronous, are fully compatible and can be mixed in the same application."
under the topic "Exception Handling: Default Synchronous Exception Model"
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
Thanks jhwurmbach,
1. You mean in the current part of the application, which handles C++ exception;
2. The current part of application invokes another model, which throws structured exception to the current part;
3. The current part of application uses set_se_translator to convert structured exception to C++ exception and catch it (since current model is designed to handle only C++ exception).
Is my description correct?
If yes, my confusion is in the project setting, we could either select /EHa or /EHsc, means only one model could be selected, and how to make the current part and the other model in my sample above to have different exception model?
regards,
George
|
|
|
|
|
Please read the configuration settings again!
Enable C++ Exceptions:
1: No
2: Yes (/EHsc)
3: Yes with SEH Exceptions (/EHa)
Maxwell Chen
|
|
|
|
|
Sorry Maxwell,
I think it is my mistake.
The important point should be,
Maxwell Chen wrote: 3: Yes with SEH Exceptions (/EHa) // Standard C++ way plus SEH.
which means enable both structured exception and C++ exception, right?
regards,
George
|
|
|
|
|
Yes.
You can create a small test project and test both ways mixed.
Maxwell Chen
|
|
|
|
|
Thanks Maxwell,
1.
So, set_se_handler works only in /EHa mode, since in /EHsc, there is no structured exception, so no need to convert, right?
2.
Maxwell Chen wrote: test both ways mixed
Confused about what do you mean both ways. In my current understanding, only /EHa mixed structured and C++ exception. /EHsc only produces C++ exception -- no mix. Correct me if I am wrong.
regards,
George
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
