|
See the hwndParent parameter at FindWindowEx function (Windows)[^]:
Quote: If hwndParent is NULL, the function uses the desktop window as the parent window. The function searches among windows that are child windows of the desktop.
You did not show us the full Create call but if you have passed CDialogBar or any other window of your application as parent you must also pass it to FindWindowEx (using this for the CDialogBar here):
CWnd* pWnd = FindWindowEx(this->GetSafeHwnd(), NULL, _T("Dialog"), NULL);
But you should think about using a member variable. The only thing to do then is clearing the pointer when the dialog is closed. Otherwise you have to check for existance also in your SomeButton function to avoid creating multiple instances of your dialog.
|
|
|
|
|
The creation of CMyDialog is:
pMyDialog->Create(CMyDialog::IDD, this);
I will try your advice, I hope to work.
"But you should think about using a member variable. The only thing to do then is clearing the pointer when the dialog is closed. Otherwise you have to check for existance also in your SomeButton function to avoid creating multiple instances of your dialog."
The CMyDialog could have only one instance, so, there is no problem with that.
|
|
|
|
|
Flaviu2 wrote: The CMyDialog could have only one instance, so, there is no problem with that.
How do you know that?
If CDialogBar::SomeButton is called again (the name indicates that it requires only a mouse click), you would have multiple instances. When using a member variable you could then activate the existing dialog instead of creating a new one.
|
|
|
|
|
The CMyDialog are closed when he lost the focus, so, there is no way to be two (or more) instances.
|
|
|
|
|
Quote: The CMyDialog are closed when he lost the focus
OK.
So it is some kind of popup or tooltip window. But the window will loose it's focus when clicking another button (as indicated by your CDialogBar::OtherButton()).
I'm not sure what happens before. So it might be that the window is already destroyed when trying to find the handle. Even if not, you should not use the handle because the window would be destroyed shortly thereafter.
|
|
|
|
|
Flaviu2 wrote:
CWnd* pWnd = FindWindowEx(NULL, NULL, _T("Dialog"), NULL);
Shouldn't the third parameter to FindWindowEx() be #32770?
"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
|
|
|
|
|
I have try also this:
CWnd* pWnd = FindWindowEx(GetSafeHwnd(), NULL, _T("#32770"), NULL);
TRACE(">>>%p\t%d\n", pWnd, pWnd->GetSafeHwnd());
and the result is
>>>00000000 0
Strange ... I guess that only member variable are safe ...
|
|
|
|
|
Flaviu2 wrote: I have try also this:
CWnd* pWnd = FindWindowEx(GetSafeHwnd(), NULL, _T("#32770"), NULL);
TRACE(">>>%p\t%d\n", pWnd, pWnd->GetSafeHwnd());
GetSafeHwnd() returns the window handle (HWND), not the CWnd* pointer.
So the result of FindWindowEx() as well as its handle being "0" is obvious!
|
|
|
|
|
Good point ! I will try that.
|
|
|
|
|
Can I say I have never seen such a ridiculously convoluted way to do this. Doing an atomic string search is first slow, and secondly mildly dangerous and unreliable.
There are two MUCH SAFER standard windows ways to do such a thing and both require you to put code on the dialog handler
1.) In the dialog itself on the WM_INITDIALOG message either post back a message dialog is open, or even just set a global variable to the dialog window. In the WM_DESTROY of the dialog post back a closed message or just zero the global variable to the dialog window.
Something like this is probably the simplest for you
HWND MyDialog = 0;
INT_PTR CALLBACK DialogProc(HWND hDlg, UINT uMsg, WPARAM wParam, LPARAM lParam)
...
case WM_INITDIALOG:
...
MyDialog = hDlg;
break;
case WM_DESTROY:
...
MyDialog = 0;
break;
...
2.) In the dialog handler itself respond back to a user WM_APP message with your handle. The message will be enumerated to all windows in your application and you will be the only responder.
INT_PTR CALLBACK DialogProc(HWND hDlg, UINT uMsg, WPARAM wParam, LPARAM lParam)
...
case WM_APP + 100:
...
return (hDlg);
...
Method 1 you simply need to look at the global variable MyDialog to know if the dialog is open or not and what it's handle is. Method 2 you use SendMessage(0, WM_APP+100, 0, 0) and if your dialog is open you will get a response back which will the handle to your dialog. If you get 0 back the dialog is not open because no other window will respond to WM_APP + 100.
In vino veritas
modified 13-Dec-16 23:17pm.
|
|
|
|
|
That is why I chosen to do m_pMyDialog as member variable, and everything it's all right now. Thank you all of you !
|
|
|
|
|
I am programming regular C for an embedded ARM processor. I need to declare an array with volatile elements inside it. The location of the array is constant, it's only the elements inside the array that can change and they are, like I said, volatile. What is the correct way to declare it?
A. uint8_t volatile UARTrxBuffer[10];
or
B. volatile uint8_t UARTrxBuffer[10];
or
C: volatile uint8_t volatile UARTrxBuffer[10];
modified 7-Dec-16 9:37am.
|
|
|
|
|
The general answer is B but in your case there is no difference between A and B, and C would generate a compiler error.
It can be better explained when having a dynamically created array:
uint8_t* volatile my_data1 = (uint8_t* volatile)malloc(10);
volatile uint8_t* my_data2 = (uint8_t*)malloc(10);
volatile uint8_t* volatile my_data3 = (uint8_t* volatile)malloc(10);
With the volatile pointers, the casts must also contain the volatile keyword.
But with arrays, the pointer can't be re-assigned so that version C is not allwed and the position of the volatile keyword does not care.
|
|
|
|
|
I am confused what Jochen is saying to you but I will say nothing you nor Jochen have code will make the items within the array volatile.
First lets cover the basics volatile is an optimizer instruction it has very little to do with the C language as such it is also HIGHLY vendor sensitive. So the first thing you always need to do is check your vendor tools and specification.
My next warning is to always put the volatile between the type and the name not at the front as people love to do. Things like the arm compilers are notorious with volatile in the front of the type and if you use it in macros you will end up with it on the wrong thing. I covered this in a recent article on baremetal with the RPi but Arm covers this in there documentation
ARM Information Center[^]
You see the format, that is not just the arm standard it is the standard I suggest you use as most embedded compilers get it right
type volatile * const ptr;
| | | | |
| | | | +------> ptr is a
| | | +-----------> constant
| | +---------------> pointer to a
| +---------------------> volatile
+---------------------------> integer/long/etc
Almost all vendor tools will fail to do with volatile what the full C specification says because the specification isn't written by embedded processor vendors and they get little say in it. Some of the junk that is in the C specification around the word volatile is ignored because it doesn't make sense in micro-controllers. The scary stat is 96% of vendor tools fail the full C implementation (Testing result reference :[^])
So lets get down to specifics the volatile must also be on any item within the array putting a volatile on the array itself will not work almost any compiler. The compiler doesn't see "blocks" of things as volatile it only sees things it is accessing in the mode it is accessing them as volatile.
The fact you want a volatile inside a malloc would tend to indicate you are playing around with a DMA controller so I will reference hardware access here. If this is just shared multitask memory nothing changes it's just simpler to understand.
This is a basic hardware register definition example for something like a DMA controller
typedef uint32_t volatile rwreg32;
typedef uint32_t const volatile readreg32;
I can then define an array of them and the volatile will be on each and every array item because when the C compiler picks up an array entry they are a type which includes the word volatile. Note if you accessed the enteries as words or bytes those accesses would not be volatile, it is that specific.
rwreg32* SomeArray = (rwreg32*)malloc(10 * sizeof(rwreg32));
You notice there is no word volatile on the array itself that is pointless and won't work unless you were passing the whole array to something. The same situation exists with structs if you wish to use them as representations of hardware. The volatile must be on each item in the struct AS IT WOULD BE ACCESSED and even down to bit packs if that is how you access them. Here is a small random sample from an OTG chipset struct
volatile const struct {
volatile unsigned SpaceAvailable : 16;
volatile unsigned QueueSpaceAvailable : 8;
volatile unsigned Terminate : 1;
volatile enum {
InOut = 0,
ZeroLengthOut = 1,
PingCompleteSplit = 2,
ChannelHalt = 3,
} TokenType : 2;
volatile unsigned Channel : 4;
volatile unsigned Odd : 1;
} __attribute__ ((__packed__)) Status;
You see how they have put volatile on each entry in the struct as they would be accessed, and as the struct itself may be accessed as a whole it is put on the struct itself.
So basically however you access the hardware must be seen as a volatile type, just putting volatile on something doesn't make it volatile as a whole if you don't access it that way. So even declaring something like a register as volatile doesn't work if you access the register as bits. Many micro-controllers have bit operations they can do on registers and special hardware and that is what those who write the C specification seem to not understand time and time again. Some vendors will allow you just to mark the register as volatile but many more require you to mark each bit within the register as volatile if you use bit operations. That is why many vendors tools have a more simple definition called SFR for special function register where they do the volatile on everything for you.
So this is why the correct way to do this is however your C tool vendor says to do it because the C standard may be of little help on anything more than a simple shared memory use of the word. In 4 revisions of the C standard the committee hasn't even managed to give us a way to define a write only register which almost every micro-controller has, so don't expect them to deal with volatile anytime soon.
If you are on something like an ARM6+ it gets worse the C standard has no idea what to do with Out-Of-Order-Execution processors like the Arm  Most of the new fancy phones run Weakly-Ordered CPU's and if you are coding for them you need to understand how to deal with it and a few more tricks you won't find in the C standard. I bring it up because on those you don't even write directly to the hardware (there is a cache between you an it) so the idea of volatile gets even more convoluted.
In vino veritas
modified 7-Dec-16 20:45pm.
|
|
|
|
|
created a Dialog base Application with Tree control..Now i had Selected some leaf item from my tree control ,And after that click on to open any dialog then the Tree Leaf unselected.
Now i want tree item should be selected after closing the dialog.
|
|
|
|
|
The selected item should remain selected after the second dialog terminates.
|
|
|
|
|
Thanks you so much for reply...
Now I tell u full story. when i drag the item into grid it also add into TreeView.Now suppose there are 3/4 item into editor and u select one the parallely tree item will also select.so now this time both the thing are selected but as u will click some where else like open an dialogbox and close it then tree item will be selected but partially it`s colour will be Gray..now my problem is that Gary colour. I need it Fully selected Item.
Please tell me what to do...
modified 5-Dec-16 7:40am.
|
|
|
|
|
If you want your item to be highlighted (blue) it must not only be selected, but the containing control must have the focus. Read up on "set focus".
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
I piece of code that is executed by 4 threads. I want to Serialize it one at a time
So I Create a Mutex handle = CreateMutex(NULL,FALSE,NULL);
I observe that the HANDLE its not NULL
Then I "dwWaitResult = WaitForSingleObject(sysblk.single_thread,INFINITE)"
(I am running this under VS debugger and have a few breakpoints before I do the ReleaseMutex)
Then finally the first thread gets to the end of the serialized code.
I do a "ReleaseMutex(sysblk.single_thread)" it returns 1 however
When I look back at the VS Threads Window and click on each the 3 threads there is an inverted arrow at the WaitForSingleObject indicating
that none of the threads were signaled
Thanks
|
|
|
|
|
|
Sorry that was a typo as I typed the code and didn't cut paste it was meant to be
WaitForSingleObject(handle,INFINITE); and ReleaseMutex(handle);
Let me ask question after the first thread goes thru the WaiForSingleObject it turns from
signaled to non-signaled then if more then one thread is waitting when the ReleaseMutex is
executed it lets only ONE thread at a time to process while the other remain waiting till
the next ReleaseMutex correct ?
|
|
|
|
|
That should be the way is works. Each thread should acquire the Mutex (i.e. lock it) in order to protect the data. When they finish the critical section they should Release it. The point being that you only want one thread through this path at any one time.
|
|
|
|
|
Sorry for the delayed response but I have been very busy at work
But can Multiple threads wait on the Mutex with the WaitForSingleObject
And then which is released with the ReleaseMutex the one waiting the longest
|
|
|
|
|
I'm not sure, you would need to run some tests to find out. But in a properly designed application it should not matter, mutexes are not supposed to be FIFO queues.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
