Make a call to the windows API command "GetWindowsDirectory" and use strcat to concatenate the notepad string to the end of it. You could just hardcode the string too (eg "C:\\Windows\\notepad.exe"), but if anyone has a custom windows install it may not find the file.
char *strbuf;<br />
if (GetWindowsDirectory(strbuf, 256))<br />
strcat(strbuf, "\\notePad.exe");<br />
// An error occurred, perhaps the buffer is too small?<br />
// Now you should have the full path in the strbuf variable<br />
When I die I'd like to go peacefully in my sleep like my father, not screaming in terror like his passengers!!!
<marquee direction="up" height="50" scrolldelay="1" step="1" scrollamount="1" style="background-color:'#44ccff'">
--Defeat is temporary but surrender is permanent
--Never say quits
--Jesus is Lord
I have to receive a very large data from my sensor via Serial Port. Here below is the structure of my data :
10 bytes HEADER + ( 4 bytes BEGIN + 240bytes DATA )*280 + 4 byes FOOTER
=> The total byte is : 10 + ( 4 + 240 )*280 + 4 = 68334 byes !
And, with such a large data, I don't know how to receive it. My buffer always overflow !!! So, now, I want to create a independent thread for reading data out of buffer, saving to other place and free the buffer sothat it can receive other data from my sensor without overflowing. I tried search "Serial Port" on this website, and I find the article about my problem. That article is "Serial Communication in Windows", posted by Ashish Dhar. I tried to use it, but I can't succeed !
So, please kindly show me how to trap create an independent thread to achieve my purpose.
Please don't ignore my question because this is my final project for graduating from my university ...
Please help me !!! My project's deadline is coming .... I really need that code ...
Thank you very much !!!
Email to me at : email@example.com
You can use AfxBeginThread() or CreateThread to invoke a new thread.
In my suggestion Create threads for reading from COM port, Parsing (if any)the received data and processing the data. So u can start 3 threads ( must be ssynchronized). The read thread reads bytes of data only and keep in a byte pointer. The parsing thread read from the byte pointer and remove any header/paddings etc & convert to pure data u need and keep. The processing thread must read from it or assign to proper data structure and do it work..
I have a finished implementation for activation that relies on the manufacturer assigned non-changable serial number of a hard drive. During testing I discovered that my method of discovering this number does not work on all versions of Windows that are going to be supported. The WMI claass Win32_PhysicalMedia does not exist in Win2k. The workaround for this is also very painful, requiring DeviceIoControl and probably administrative priveleges at runtime. I noticed that there is Wmi32_BaseBoard class that provides a serial number. However, not all motherboard provide this information (driver code never sets the number).
What is a good, simply way to identify a machine that works consistently on Windows 2000 and newer?
Note that the forth parameter gives you the volume serial number that the operating system assigns when a hard disk is formatted. To programmatically obtain the hard disk's serial number that the manufacturer assigns, use the Windows Management Instrumentation (WMI) Win32_PhysicalMedia property SerialNumber. But obviously you already know that Win32_PhysicalMedia doesn't work in less than WinXP
GetVolumeInformation can be easily changed and does get changed after formating. I got a good suggested at ms newsgroups... using Win32_ComputerSystemProduct. Its a class that is designed to uniquely identify a computer. So far so good.
My knowledge of MFC and ActiveX is very minimal at best. I have been trying my best but getting no further to getting a working demo running, despite the apparent simplicity of it.
The problem seems to be that the client part of Han's code is the fact that it is done as a CDialog app while the Scribble demo is done as a CFrame. Also the ActiveX initialisation is hidden away inside InitInstance.
It's all very frustrating. What I would like is either a link to a demo/tutorial where someone converts a simple MFC app to ActiveX - Steve Zimmerman's article isn't very in depth and adds to much clutter that confuses the issue. Or I would like a very clear tutorial. A lot of the tutorials I have read are very terse or don't touch any of the concepts that I would like to know about.
While I don't want to be spoon-fed I would like a few pointers to where I can find the information or specific terms I should be searching for.
This is as good as any place to ask, ActiveX is realy a ATL/COM thing thou.
I realy could not explane it with out actualy doing it, and then I would probably need a good book on ATL/COM handy. In VC6, I would probably start by creating an ActiveX control shell, using the "MFC ActiveX ControlWizard", and then porting the code into it piece mill (testing as I went), if possible.
Sorry, I do not know any totorials on porting like this. Most assume that you are building an ActiveX control from the start.
In VC6, I would probably start by creating an ActiveX control shell, using the "MFC ActiveX ControlWizard", and then porting the code into it piece mill (testing as I went), if possible.
That's the problem - ones done in a Dialog and it seems you can only use dialogs as a dialog in ActiveX.
C# is a lot nicer as it hides all the cruft away and you can get on with the coding. However MFC generates zillion comments and macros which I have no idea what they all do. Some articles delete them while others say to leave them alone.
Now Borland Builder (5 or 6) doesn't seem so bad...
Generalizing/Seperating is a problem, in MFC you can create an CRichEditView. But the CRichEditView is the top of the food chain, at the bottom is the actual RichEdit control. You can use the control seperate from the the view (like in a dialog), but you would might have to provide your own programmers interface.
CRichEditView provides a programmers interface that provides wrapping for the CRichEditCtrl programmers interface, which provides wrapping for the actual RichEdit control interface (IRichEditOle). The RichEdit control is not dependent on MFC (as far as I know).
The general idea is to seperate the code that actualy does the work from the type of window where the results are displayed, if possible.
Yes, I know it sounds very complicate (and it is), but that is what it amounts to.
Personaly I hate dealing with COM at the lowest level, that's why wizards are so important. Imagine trying to write all that code youself.
If you can and are allowed to convert the code into C#, provided it will make life easier, then go ahead. From what I have seen, sooner or later, some one will be asking if there is a programmer that can convert the C# code to C++.
I know none of this realy helps you, but I thought I would give you my general veiws on the subject.
It should just be called for you automatically. That's the point of an overrided method.
However, if all cars have a type, then it should be stored in a variable that exists in the base class, and the GetType method should exist only in the base class. The derived classes should just set that variable.