|
The Documentation says DDX_Text is for a edit control and I am getting an assertation
So maybe I have to use GetDlgItem and SetWindowText to set the text of the CTEXT
Thankx
|
|
|
|
|
What assertion, and what code?
|
|
|
|
|
I apologize I had the wrong dialog identifier thus the wrong dialog control
|
|
|
|
|
ForNow wrote: The Documentation says DDX_Text is for a edit control and I am getting an assertation
So maybe I have to use GetDlgItem and SetWindowText to set the text of the CTEXT
You can use DDX_Text for static controls.
Another way is to create the control member variable (using DDX_CONTROL) and then use this variable to call SetWindowText.
Where and how do you call the DDX_Text from? Perhaps you call it before the base class OnInitDialog was called?
|
|
|
|
|
I apologize I had the wrong dialog identifier thus the wrong dialog control
|
|
|
|
|
My Cdialog (modeless) is looking for some user input
Therefore the modal dialog I want to save and process the input
so to get the info I do a DoModal I save the info in the modal CDialog Class (created on the stack) when myokhandler returns (this is only when the user press "X" in the right hand window corner)
It return to the CDialog procedure that called the DoModal however the data doesn't seem to be valid
Isn't the storage for modal dialog still intact till I do the EndDialog ?
|
|
|
|
|
ForNow wrote: ... this is only when the user press "X" in the right hand window corner
When the user press "X" in the right hand window corner no data from dialog controls are read in the control data variables. It is by design.
If you'd like to change this default behavior then you had to override the OnCancel method.
|
|
|
|
|
The data was saved in the Class/Object storage in my Onok handler
Does it not remain intact till I do the EndDialog which I do from the routine which did the the DoModal ?
|
|
|
|
|
The Data is probably still there you have blown the stack I suspect. Read the documentation again
CDialog::OnCancel[^]
Read it carefully because it is very specific.
If you implement the Cancel button in a modeless dialog box, you must override the OnCancel method and call DestroyWindow inside it. Do not call the base-class method, because it calls EndDialog, which will make the dialog box invisible but not destroy it.
So your Dialog when cancelled will be invisible and not destroyed and I suspect your stack just got toasted hence the reason for the big warning.
So do what it asks override the OnCancel method calling DestroyWindow inside it because there is a reason the framework requires that and I am guessing not doing it will be a very bad idea. I can't tell you why it has to do that it is something to do with the framework implementation.
In vino veritas
|
|
|
|
|
ForNow wrote: The data was saved in the Class/Object storage in my Onok handler
So the OnOK() method is being called when you click the "X" in the upper-right corner?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
No David its a Modeless dialog pressing the Ok button doesn't close the dialog like on a normal modal dialog.
To close the dialog right now he is using the "X" in the upper-right corner.
He is probably going to put some other button on screen to exit but its a stock standard modeless dialog.
His comment above makes perfect sense in that light, he put data in a structure shouldn't it still be there and the answer is normally yes.
The problem is his exit he is doing isn't as per what the framework manual specifies for modeless dialogs.
The framework specifies the exit for a reason, hence its a good guess the problem is ... and bad things are happening 
In vino veritas
modified 18-Apr-16 10:32am.
|
|
|
|
|
leon de boer wrote: No David its a Modeless dialog pressing the Ok button doesn't close the dialog like on a normal modal dialog.
As long as that method calls DestroyWindow() rather than CDialog::OnOK() (which internally calls CDialog::EndDialog()), the dialog will close just fine.
leon de boer wrote:
He is probably going to put some other button on screen to exit but its a stock standard modeless dialog.
There is no standard that dictates what UI element is used to close a modeless dialog. It could be Esc, the "X", Alt+F4, or a Cancel/Close button. Instead, it's what the code behind those elements do that's important.
I'm well aware of how modal and modeless dialogs behave. My question was not because I wanted to know the answer to something; it was instead asked to make the OP reconsider his design. Clicking the "X" button should call OnCancel() method.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Hi
I have a CAsynSocket as a member of a CwinThread (having each socket connection in its own thread)
The program is acting as Client When I do a connect everything goes as a planned I get the
OnConnect Notification and OnSend (though they always come in the context of the Main
Thread).
Since I would like to know when this happens I Wait on a CEvent. The CEvent is a member
of the CwinThread. The only problem is that when I do the WaitForSingleObject
nothing happens (as far as notification OnSend OnConnect)
|
|
|
|
|
WaitForSingleObject will suspend the entire thread it's running in
So your OnSend and OnConnect code better not be on that thread or they will never be called which is what you are saying !!!!!!!
It's called a deadlock the only thing that can release the WaitForSingleObject is an event that will never be sent because the detecting code to create the event will never run.
Sounds to me like you need to get out a pen and paper again and work out the logic of the threads.
In vino veritas
|
|
|
|
|
Hi
Thanks I think that in any scenario (CAsynSocket being a member of a CWinThread)
socket notification always happen in the context of the main thread
|
|
|
|
|
First off let me say I am by trade a MainFrame Programer
In Z/os you can issue a wait anywhere in a task or thread and it will suspend that unit of work or program. In MVS many programs comprise a task
The program information is saved in a RB block
But the task or Thread doesn't stop
I understand this is not the case in Windows
|
|
|
|
|
You need to understand this isn't even about Windows you are using a framework and you need to understand the framework.
Windows if you were dealing with the API can do some very different things and in your case the framework determines the behaviour because it was designed with a concept in mind.
Since you seem to need proof the thread is blocked make the wait 10 seconds and look for the timeout
DWORD Ret=WaitForSingleObject(yourEvent, 10000);
if (Ret==WAIT_TIMEOUT)
{
TRACE("*** Houston we have a Timeout ... Thread blocked LdB right ***\n");
}
If I am right you will get that message 10 seconds later .. so easy to test with 3 lines of code
The solution is play nicely with CAsynSocket or go direct down onto the Windows API and do the socket work yourself. I don't doubt your programming ability just your understanding of the Framework.
In vino veritas
modified 17-Apr-16 3:48am.
|
|
|
|
|
I don't need proof I know you are right thanks for explaining
|
|
|
|
|
Changing the visual style of an application causes handle leaks. In CMFCVisualManager there exists a function UpdateSystemColors, which is called three times when the style is changed. Every call opens theme handles. Below the UpdateSystemColors is a function CleanUpThemes, which closes the theme data handles. This function is only called once when the style changes. This causes 38 handles which will not be closed afterwards.
I've looked for a possibility to fix this in source code, but this needs to compile the MFC lib on my own, but there is no makefile for it...
Any thoughts?
|
|
|
|
|
Hi All,
I am struggling these days in creating an MFC application which has following problem statement:
--> In MFC, Create an UI list control which will
populate data from one table using db connectivity.
What I have done so far :
--> Created a SDI MFC application,
--> Able to connect to db, fetch record in "Edit Box" and traverse between records(First,Last,Next,Previous).
where I am stuck:
--> I am not able to populate these records in List control. I have taken reference from "c++ - How to add items to a List Control in an MFC dialog - Stack Overflow[^]"
but it has asked to write code under "OnInitDialog" method which is not present in SDI application. Though I can able to see this method in Dialog based MFC application but not in SDI application.
Request you to all to please help me.
Thanks,
Sanjeev
|
|
|
|
|
With not dialog based applications you should derive your view class from CListView Class[^]. That can then be populated with the recordsets using the CListView::GetListCtrl[^] function to get a reference to the list control. The OnInitDialog() corresponding function for views is CView::OnInitialUpdate[^]. See also the example code at the GetListCtrl() link.
|
|
|
|
|
I don't understand clearly what is the difference between compiled and interpreted? As they all are translated to another language when they are build.
|
|
|
|
|
|
Mur2501 wrote: As they all are translated to another language when they are build.
That's just it... interpreted languages aren't really translated to another language, they are kept in their original format until run by the user. When the user runs the program, he's really running the interpreter, which takes the script in and interprets what is to be done.
The definition is not always as cut and dry as you might think, there are a lot of languages nowadays that produce byte-code or some other in-between by-product that will be further interpreted at run-time.
|
|
|
|
|
Another difference to consider is their behavior.
For an interpreted language, the program is run line-by-line when you request it to run. If there is a problem in the logic or any other 'bad things', it will run until it hits one. Thus, if you misspelled a variable's name it wouldn't react to it until you run it and it happens to come across the misspelled version. Also, if you left out a BEGIN or END statements, it would run until that caused a problem, if ever. Some feel that these languages are easier for beginners to start with because they're not all-or-nothing, but not everyone agrees with that.
Now, for a compiled language, the entire program is converted to 'machine code' (often in several steps). This code has to take the entire program into consideration at once. If you have a problem it will not be able to figure out what to do and you'll get an error. The program will NOT be compiled. A misspelled variable is 'undefined' and would be a problem. Similarly, the compiler will look for an END for every BEGIN, in the correct order or it will be an error. Compiling a program is an all-or-nothing affair.
Because of this difference in when the program is turned into real computer instructions, the interpreted languages are much slower than compiled languages when running.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
