|
Hi, I'm looking for a MFC/Vis C++ example of a rotary dial control. I located one in the CP archives, but thought there were others.
http://www.codeproject.com/miscctrl/rotary.asp
Any help? 
Thanks,
Johnny
|
|
|
|
|
you could try this[^]
Error 4711: Signature expired
|
|
|
|
|
I liked this one:
http://www.marvgolden.com/health-safety/relief_bands.htm
 -- seriously though, was looking for a quick one that you might know about.
|
|
|
|
|
Thats what I call a "reusable component" 
Error 4711: Signature expired
|
|
|
|
|
hi
i am using EnumPrinters() function in my project. this is working fine. in msdn help they given if EnumPrinters() successfully executed it returns nonzero value otherwise zero value. but i am getting zero value for successful working of EnumPrinters(). so which one is right please clarify my doubt
thank you
|
|
|
|
|
Try to catch a CDBException like this:
try
{
}
catch (CDBException* e)
{
AfxMessageBox (e->m_strError);
e->Delete ();
}
It may give you useful information
Best regards,
Alexandru Savescu
P.S. Interested in art? Visit this!
|
|
|
|
|
Does anyone know what is the preferred what to pass variables to a function ? Assuming the value does not need to change.
For example I was just recently old that
foo( long val ) was preferable to
foo (const long& val )
Isn't the second form more efficient ? I had always thought this, plus the use of "const" clearly marking something as not changing. Any thoughts welcome here
¡El diablo está en mis pantalones! ¡Mire, mire!
|
|
|
|
|
const reference is what is favoured by the 'gurus', like Scott Myers and the like.
in case of a long int, it may make no big difference, but when you have to transfer an object of several hundreds of bytes, things are different.
As for the const, it simply is a good habit, giving the compiler the opportunity to assist you in adhering to your own guidelines.
|
|
|
|
|
The const is important for the optimizer. It allows the caller more freedom to optimize since it knows the callee won't change the value.
However, for small values that can normally be passed on the stack, using a const reference will slow things down. So for ints, longs, etc..., don't use a const reference. Just pass the value normally.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
For built-in types, there is no copy constructor that may cause unwanted side-effects when passing by value. For user defined types, there may be side effects when (if it is even possible to) passing by value which invokes the copy constructor. That's why passing by reference is generally better for user-defined types-- you're just passing the ability to access the same object instead of a copy of the object. (and if you will make no changes, pass a reference to the object as const.)
|
|
|
|
|
Hmmmmm - the copy constructor that you are talking about would be called buggy here.
Either it does its work flawlessly or it is impossible to call (private).
|
|
|
|
|
That is not necessarily true.
A copy constructor can have unwanted side
effects that are not bugs.
Take for example, auto_ptr.
Its copy constructor will pass ownership
to the copy being passed to the function
in question. Upon return, the original
auto_ptr will no longer point to a valid
object, it having been destroyed when the
function's copy of the auto_ptr deleted
the object. This is almost certainly not
what the designer of that function nor its
user would desire.
|
|
|
|
|
Well, std::smart_ptr is something special with its odd, but documented behaviour.
AFAIK is a reference on a std::smart_ptr also doomed: If it goes out of scope the contained ptr gets deleted, even if another reference elsewhere is still there, leading to an error when it goes out of scope.
So I tend to not use std::smart_ptr and use boots shared_ptr, which uses reference counting to show an intuitive behaviour.
For me, the std::smart_ptr behaviour, even if documented, looks like a bug, smells like a bug - must be a bug.
The same would be a class that, well documented, overrides opeator< with "true on less or equal": Allowed but extemely buglike. You can't sort anymore.
|
|
|
|
|
To add to what others have said:
1. Passing by value has the added perk of letting you to change the value of "val" inside your function (just like any other local variable), which may prove convenient.
2. Passing by const reference gives the possibility for the function to actually alter the value of "val" by casting away the constness. I know this is silly since most likely you're the one who's writing the function, but it does add to why its just better to pass native types by value instead of const reference.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
|
|
|
|
|
Hi all.
When not using the "Document/View architecture support" in the step 1 of AppWizard, Must the view of a program be an object whose class is derived from CWnd?
i wanna write a program without "document/view architecture support" and its view is a CView object or a CHtmlView object. i try accept the default value(using the object whose class---CMyView derived from CWnd as the view), and after finishing the wizard, i change the base class of CMyView from CWnd into CHtmlView(include the BEGIN_MESSAGE_MAP macro, IMPLEMENT_DYNCREATE macro), it can run, but it crashes when it close. why?
|
|
|
|
|
Grant Chan wrote:
view is a CView object or a CHtmlView object
Well, every CHtmlView IS derived from CWnd: CWnd::CView::CScrollView::CFormView::CHtmlView is the chan of derivations.
Grant Chan wrote:
it can run, but it crashes when it close. why
What? When? Where?
Need input!
|
|
|
|
|
First thanks for your reply.
jhwurmbach wrote:
Well, every CHtmlView IS derived from CWnd: CWnd::CView::CScrollView::CFormView::CHtmlView is the chan of derivations.
i known that CWnd::CView::CScrollView::CFormView::CHtmlView is the chain, but my question is why CMyView can be derived from CWnd, but cannot be derived from CHtmlView?
jhwurmbach wrote:
What? When? Where?
Need input!
debug assertion failed
Program: ...
File: dbghelp.c
Line: 1011
Expression: _CrtIsValidHeapPointer(pUserData)
|
|
|
|
|
Grant Chan wrote:
my question is why CMyView can be derived from CWnd, but cannot be derived from CHtmlView?
Oh, I see. Sorry for missreading you!
So, you got an dialog-based application, right? That Is, your main Window is derived from CDialog. So you can't simply drop in a CView-derived CHtmlView which depends on having a document to work with. You would need a single-document doc/view program for providing the doc/view infrastructure.
But you can surely place a IE-window on your dialog, using COM and the like.
I have no idea how you would do this in detail, though.
Sorry for being not helpful
|
|
|
|
|
No. my application is an SDI application
|
|
|
|
|
Oh, well, then its simple!
(If you happen to have a similar problem yourself before and spent a whole day googling for a solution, that is
Look at the call stack in your debugger: You will see that the first function (counted top down) with a familiar name is CView::PostNCDestroy().
Clicking on that line you see a 'delete this;'.
CViews are meant to be constructed on the heap and delete themself after use. You have constructed your window on the stack.
So sumply override PostNCDestroy() in your derived class and do not call the base class.
That should do it!
|
|
|
|
|
jhwurmbach wrote:
do not call the base class
i just overrided the CMyView::PostNcDestroy() with nothing:
void CMyView::PostNcDestroy()
{}
it works(thank god), but i still wanna know how can i simply do that, i mean i'm afraid that will be a memory leak, cos' that's a "delete" operation originally.
And note that if i use MFC appWizard with "Document/view support" checked and change the base view class from CView into CHtmlView, there is no need to override the PostNcDestroy function, it will close successfully. why must i do that?(do u think i'm boring...?)
whatever, thanks again for your help above.
|
|
|
|
|
Without doc/view you don't need to (you must not) delete, because your CHtmlView is on the stack (you simply made a variable like 'CHtmlView htv;').
As you probably know (I dont know your programming background), delete is for disposing variables made on the heap (as in 'CHtmlView* pHtv = new CHtmlView;'). Calling delete on a variable that is not on the heap (or calling it twice) is not correct.
If you check doc/view in the App wizard, MFC constructs your CView (or derived class like CHtmlView) somehow 'behind your back', using new.
In this case, when the View decides it has to go away, it calls 'delete this;', and frees its own memory.
|
|
|
|
|
After finding the creation of view by MFC, i feel it's pretty implicit(created in CreateObject() ).
|
|
|
|
|
How do I change the cursor when the mouse pointer is on a button or on a notified picture???
|
|
|
|
|
There is a message WM_SETCURSOR. Deal with in your control and your are ready.
Try it @ home. (B&B)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
