|
Cheers 
Top of the day to you too! 
|
|
|
|
|
It seems that the following format "%f\n" for reading a double not working. Please help:
fscanf( f_ptr_seed_inf,"%f\n",&sam_interval);
Thanks
|
|
|
|
|
Start here. Then look for double
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
In the future... describe what you mean by "not working". Think about it, if you were a mechanic and I told you "my car isn't working", would you know what's wrong?
|
|
|
|
|
the driver of course.
|
|
|
|
|
 I use lmgtfy these days where I previously would have said RTFM.
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
|
In the application that I am working on, the main screen has a toolbar with 10 buttons on it. Those buttons represent various actions (e.g, clock in, gone to lunch) that the user can take. The user has control over which image they want assigned to which button (based on the button's action). There are 50+ bitmaps to choose from. My interface thus far for this is a list control with an image list housing the 10 bitmaps currently in use. When an image in the list control is clicked, information about the button's action (7-8 other controls) is displayed in the lower half of the dialog. That information, including the image, can be changed.
The predecessor to this application, which is around 10 years old, just had a "change image" push button that displayed another dialog. This second dialog simply had a listbox with the names of the bitmaps in it. The currently selected bitmap was displayed in some sort of picture control above the list. If you can envision this from my description, it's rather dull and old feeling. What I'm looking for is a "modern" way of being able to change the bitmap assigned to the toolbar button.
Can you toss some ideas out on the table of ways you can think of that would make this scenario a little less Borland/Ctl3d feeling? My job still requires me to use VS6 so I'm not up-to-date on all of the latest UI elements that VS (and Windows 7) offers. I've played around with VS2008 for some personal and proof-of-concept stuff, but nothing mainstream.
Thanks.
- DC
"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
|
|
|
|
|
Well, the good thing about C++ is that you can make your own controls... and draw everything however you want (of course, this involves you programming it yourself, hope you're good with GDI... ).
Since you're just changing icons, how about a right click option that loads a handful of icons at a time along with their labels (sort of like a menu pulldown with icons)? This is very doable in studio 6 but you'll have to program the icon loading yourself, the menu display portion is relatively straightforward (you can make a static menu with all the options, then just load the icons).
Another option would be to make a window with no borders that just has a number of icons on it for the user to select from. You can probably also tie that in to a right-click or something like that.
|
|
|
|
|
Albert Holguin wrote: Another option would be to make a window with no borders that just has a number of icons on it for the user to select from. You can probably also tie that in to a right-click or something like that.
I had thought about this option but wasn't sure how to create a dynamic list control. What I've tried, in response to a right-click, looks like:
CPoint pt;
GetCursorPos(&pt);
ScreenToClient(&pt);
CRect rc;
rc.left = pt.x;
rc.top = pt.y;
rc.right = 5 + 398;
rc.bottom = 5 + 293;
CListCtrl *lc = new CListCtrl;
lc->Create(WS_CHILDWINDOW | WS_VISIBLE | WS_VSCROLL | LVS_ICON | LVS_SINGLESEL, rc, this, IDC_LC_BITMAPS);
lc->ShowWindow(SW_NORMAL);
lc->InsertItem(0, _T("IMAGE 1"));
lc->InsertItem(1, _T("IMAGE 2"));
This shows up...sort of. The dynamic list control does not appear to cover the controls behind it like it would if it was in a separate modal dialog. When I mouse over it, the other controls start bringing themselves to the front.
Also, how to get responses from the dynamic list control? Would ON_NOTIFY_REFLECT() work?
"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
|
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
