|
|
Not sure how I'd go about getting the messages back from the control, however - have you tried using CreateEx, making sure to specify the flag WS_EX_TOPMOST?
|
|
|
|
|
enhzflep wrote: ...have you tried using CreateEx, making sure to specify the flag WS_EX_TOPMOST?
Yes, no difference.
"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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Bugger!
Guess then it seems fitting that I've just found this 'gem'
INFO: Overlapping Controls Are Not Supported by Windows[^]
I guess that leaves fewer options.
You could try to:
- disable/hide controls whose bounding-box intersects that of the listView.
- float a new listView window above the app (WS_POPUPWINDOW | WS_VISIBLE | WS_VSCROLL | LVS_ICON | LVS_SINGLESEL)
- float a window of a userDefined window class above the app, and stick the listView onto that - This would alleviate the need to subclass the ListView as all mouse-out behaviour could be handled by the new window
|
|
|
|
|
enhzflep wrote: float a new listView window above the app (WS_POPUPWINDOW | WS_VISIBLE | WS_VSCROLL | LVS_ICON | LVS_SINGLESEL)
This is what I've been trying (i.e., dynamic list control). The WS_POPUP style keeps asserting (line 750 of wincore.cpp). I also tried to derive my own class from CListCtrl and override the Create() and CreateEx() methods. No difference.
enhzflep wrote: float a window of a userDefined window class above the app, and stick the listView onto that - This would alleviate the need to subclass the ListView as all mouse-out behaviour could be handled by the new window
I'll give this one a shot.
"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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
David,
If you want to use a pop-up CListCtrl then (as the Microsoft help article hinted at) you can fix those redraw problems by setting the parent to GetParent() instead of 'this' and then call list.SetOwner(this). Also remove that WS_POPUP style. When you show the CListCtrl set it to CWnd::wndTopMost with the SWP_NOOWNERZORDER flag.
Have you considered extending the Generic Picker Dropdown Control[^] by our old friend Iian Clarke? You could probably derive a class from his CGenericPicker and have it draw the contents of a CImageList.
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: Have you considered extending the Generic Picker Dropdown Control[^] by our old friend Iian Clarke? You could probably derive a class from his CGenericPicker and have it draw the contents of a CImageList.
I looked at this one, as well as the one by Hans D, and both appear to "sit" directly on top of the control that created them without a hidden CWnd in between. If I had my druthers, I would prefer this method as it eliminates an extra window. Is it the SetCapture() that keeps the new control on top until a selection is made?
While playing around with all of this eaarlier, I was crudely able to get a window to popup over my list control (correctly covering the other controls), but it was possessed and would not go away when I clicked outside of it. Closing the dialog behind it was the only way to kill it!
"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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
DavidCrow wrote: Is it the SetCapture() that keeps the new control on top until a
selection is made?
Well the SetCapture() function is simply to ensure that the window recieves mouse input regardless of what/where the mouse is hovering. The control closes when a selection is made because the control is handling the WM_LBUTTONUP message (Yes, it recieves this message even if the user clicked on another window because of SetCapture). The control closes the window when it loses focus because the control is handling the WM_KILLFOCUS message. By handling both messages... it ensures that the window will close if the user is using keyboard navigation (WM_KILLFOCUS) or clicking around with the mouse (WM_LBUTTONUP).
DavidCrow wrote: While playing around with all of this eaarlier, I was crudely able to get a
window to popup over my list control (correctly covering the other controls),
but it was possessed and would not go away when I clicked outside of it.
Closing the dialog behind it was the only way to kill it!
Windows do not close by themselves so you would need to derive a class from CListCtrl and handle the WM_KILLFOCUS message to have the window close when the user changes focus to another window. Handle the WM_LBUTTONUP message to close in response to a user selection (should also fire if the user clicks outside the window if you called SetCapture). I would also recommend closing in response to the VK_RETURN and VK_ESCAPE keys. (It doesn't look like Iian was doing this in his control)
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: (It doesn't look like Iian was doing this in his control)
I'm beginning to see why. The only message I can get reflected back to my list control is NM_CLICK. The messages WM_KILLFOCUS, NM_KILLFOCUS, and WM_LBUTTONUP are all ignored. I think this is by design with list controls.
"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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
modified 22-Mar-12 10:33am.
|
|
|
|
|
Hi,
DavidCrow wrote: I'm beginning to see why.
He is not using a CListCtrl based class he is using a CWnd based class. I was actually referring to the handling of VK_RETURN and VK_ESCAPE keys for closing the window in that comment.
When you use these default Microsoft controls you are sometimes limited by their design because they are already subclassed by MFC. The CListCtrl probably handles the WM_LBUTTONDOWN/WM_LBUTTONUP messages internally and then posts a WM_NOTIFY message to its parent containing NM_CLICK in the NMHDR. So I guess this implies that you would need a CWnd wrapper window if you insist on using the CListCtrl to display your images.
Btw are you sure you did not catch the WM_SETFOCUS/WM_KILLFOCUS messages? I am fairly certain you should be able to catch those messages.
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: Btw are you sure you did not catch the WM_SETFOCUS/WM_KILLFOCUS messages? I am fairly certain you should be able to catch those messages.
Thanks, David.
See my update here.
"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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
David,
DavidCrow wrote: See my update here.
It appears that you are having some success and that is great!
I looked through some of the MFC source code to find out why the WM_LBUTTONUP message is being eaten by the CListCtrl and it is because the CListCtrl handles the WM_LBUTTONDOWN message... and inside the WM_LBUTTONDOWN handler it calls CRectTracker::TrackRubberBand[^] and unfortunately this begins a modal message loop[^] that eats the WM_LBUTTONUP message.
Even subclassing the CListCtrl will not help here because GetMessage() retrieves messages directly from the system message queue (Your subclassed CListCtrl WndProc would not even get the message because of this). So you are doing the right thing by using a CWnd wrapper window.
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: (Your subclassed CListCtrl WndProc would not even get the message because of this).
This is consistent with what I was seeing. No biggee, though. Handling WM_LBUTTONDOWN is sufficient.
"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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
hello sir , i am a final year student of engineering and i met an difficulty in my project work.if any information to sending and receiving message of temperature which sense by LM-35 sensor gsm modem sim 900 with 8051 microontroller.
so, kindly inform me if any.
thanking you in advance.
Bhagwandas
|
|
|
|
|
This is a C/C++ forum and you did not ask any C/C++ related question. Please be more more specific.
|
|
|
|
|
Are you using oneof these?
"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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
You have to use whatever API was provided for the modem itself, meaning it's completely implementation dependent. I have noticed GSM modems tend to use the same instruction set[^]. Since it's text based, it can really go over anything, COM port, serial port (COM/USB), ethernet.
|
|
|
|
|
i have two to three different class here want to send message from class to another class .
please reply soon
Best Regards
sarfaraz
|
|
|
|
|
Show us what you have done. and by adding a line "please reply soon" you may not get what you want. You need to give the proper information,
If you are not sure or dont know how to do something there is a site which can give you some insight. here is the link [^]
Every new day is another chance to change your life.
|
|
|
|
|
in OOP speech 'sending messages' usually translates to 'calling methods'. Hence your classes might provide public methods for 'sending messages'.
If you meant something else, please let us know (that is: "be more specific!").
Veni, vidi, vici.
|
|
|
|
|
In MFC speech however, it has a very specific meaning, and this is a C/C++/MFC forum. So just need clarification on what he's done and whether he's using MFC.
|
|
|
|
|
thank you all i got it ..
and sorry for the improper information
thanks
|
|
|
|
|
If you're talking about sending messages within the Windows environment, it's relatively simple given that you've subclassed from the proper MFC classes. You can use a number of them so share a bit of code and we'll let you know what's your best option.
|
|
|
|
|
1>c:\msw_give_out\void_effect_no_input_msw_shotplus_i_format\blast_vib_procdlg.cpp(1908): error C2666: 'pow' : 6 overloads have similar conversions
1> c:\program files (x86)\microsoft visual studio 10.0\vc\include\math.h(583): could be 'long double pow(long double,int)'
1> c:\program files (x86)\microsoft visual studio 10.0\vc\include\math.h(581): or 'long double pow(long double,long double)'
1> c:\program files (x86)\microsoft visual studio 10.0\vc\include\math.h(535): or 'float pow(float,int)'
1> c:\program files (x86)\microsoft visual studio 10.0\vc\include\math.h(533): or 'float pow(float,float)'
1> c:\program files (x86)\microsoft visual studio 10.0\vc\include\math.h(497): or 'double pow(double,int)'
1> c:\program files (x86)\microsoft visual studio 10.0\vc\include\math.h(122): or 'double pow(double,double)'
1> while trying to match the argument list '(float, double)'
1>c:\msw_give_out\void_effect_no_input_msw_shotplus_i_format\blast_vib_procdlg.cpp(1909): warning C4244: '=' : conversion from 'double' to 'float', possible loss of data
1>c:\msw_give_out\void_effect_no_input_msw_shotplus_i_format\blast_vib_procdlg.cpp(1923): error C2666: 'pow' : 6 overloads have similar conversions
1> c:\program files (x86)\microsoft visual studio 10.0\vc\include\math.h(583): could be 'long double pow(long double,int)'
1> c:\program files (x86)\microsoft visual studio 10.0\vc\include\math.h(581): or 'long double pow(long double,long double)'
1> c:\program files (x86)\microsoft visual studio 10.0\vc\include\math.h(535): or 'float pow(float,int)'
1> c:\program files (x86)\microsoft visual studio 10.0\vc\include\math.h(533): or 'float pow(float,float)'
1> c:\program files (x86)\microsoft visual studio 10.0\vc\include\math.h(497): or 'double pow(double,int)'
1> c:\program files (x86)\microsoft visual studio 10.0\vc\include\math.h(122): or 'double pow(double,double)'
1> while trying to match the argument list '(float, double)'
How to fix the error?
Thanks
|
|
|
|
|
A good help would be if you have posted the line where the error occurs.
However, the error states that you are calling the pow function with the first argument being a float, and the second one being a double. But there is no overload of the pow function for these argument types. You should cast one value to the type of the other:
float f1 = 2.0;
double f2 = 3.0;
double f3 = pow(static_cast<double>(f1), f2);
A general note:
If you did not need the float type for a specific reason (usually memory), you should consider to always use double.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
