|
_spawn, CreateProcess, WinExec and ShellExecute are all popular methods.
-c
A conclusion is simply the place where someone got tired of thinking.
|
|
|
|
|
For a command line:
Use system if you want the command line interpreter to handle it.
Use ShellExecute/ShellExecuteEx if you want the Windows shell to handle it.
Use CreateProcess if you want Windows to handle it.
|
|
|
|
|
I try to write a program to talk to a external device via com port1. I use WriteFile() to send the ascii command: I verified to see that the ASCII command that I send out does go out to the port. I checked the correct configuration for the port(baudrate,stopbit...). But the devide still does not respond. However, the device is responding when I use windows hyperterminal to send the exact ascii command. Does anyone know why?
Does hyperterminal terminate the stream it sends out with a special ascii value that my program doesn't ?
Please help!
Thanks, peter.
|
|
|
|
|
Nope. After setting up the DCB with SetCommState and the timeouts with
SetCommTimeouts, sending out the commands via WriteFile should be enough.
Hook up COM1 to COM2 via a null-modem cable. Connect to COM2 via terminal emulator (Hyperterm or whatever.) and pretend you are the device. Connect your program to COM1 and check out what is being sent.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
