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.
Well, my way, there is no individual info method. However, in either case, you should find you're calling it in your original code. If not, perhaps you need to store a pointer instead of a class instance, perhaps it's being downcast by std::list at the moment ?
I am developing an application for WinCE 3.0 for a Pocket PC 2000 device in C++ using MFC / WinAPI.
In my application I use a Bluetooth CF card to communicate with a wireless printer. The drivers installed assign a COM port to the printer so I may
read / write to it using WinAPI calls for Files such as:
The wireless printer conserves battery by automatically turning off after a period of inactivity, so at times I must check to see if it is there before the user tries to print something.
The problem is that if I want to know anything about the file I must first get a handle with the CreateFile( ... ) function, which lags about 10-15 seconds before it times out if the printer is off, so usually the user is already trying to print something by the time I get back from that function call. Or if I make the user wait until I get back, they will get frustrated after so much time.
I tried using
CFile::GetStatus( ... )<br />
but it doesn't seem to work for COM ports, eg. I can call: HANDLE hPrinter = CreateFile( _T("COM4:"),...);
and I get the handle but if I do this: BOOL bIsPortAvailable = CFile::GetStatus( _T("COM4:"), ...);
I get FALSE back;
Is there a way to specify the timeout for the CreateFile( ... ) function or another way to check if that COM port is available?
You could try polling the printer to see when it's off. That way when a user tried to print, the status would already be off unless it just turned off a few seconds before the user tried to print.
I think you might get more responses if this post were moved to the WinCE forum? I've noticed lots and lots of function calls give me major lag on WinCE when they don't on WinXP, so you're more likely to get someone who knows how to solve the problem over there.
Sure. You could use MAPISendMail (PSDK) to send mail from the application. You could easily provide the registration information in your desired format within the message object, and just show the user a read-only copy (out of niceness).
To the same end, there are also third-party add-ins that you can add to your app to handle mail sending.
Remember, though, that if you want to process these incoming registration messages automatically, some SMTP servers change the content of email messages. For example, my office e-mail scans for viruses and adds a line indicating the messages has been scanned for viruses at the bottom of the message.
After reading http://www.codeproject.com/internet/cimapi.asp,
I am able to send email from my application.
However, it got a minor issue.
My email body is about 10 lines with about 200 characters.
I have "\r\n" to separate each line. The AfxMessageBox
displayed the text correctly, 10 separate lines.
But, the mail.Text ( ) concatenated my data to a
huge BIG string.
Just off the top of my head, assuming you want the 4th Wednesday of nMonth in nYear:
1. Create a COleDateTime for the 1st of nMonth in nYear at noon.
2. Use GetDayofWeek to find out what day it is.
3. Determine nOffset, how many days it is 'til the first Wednesday of nMonth.
4. Create a COleDateTimeSpan of (nOffset + 21) days.
5. Add this COleDateTimeSpan to the COleDateTime from step 1.
I've killed again, haven't I?
Last Visit: 31-Dec-99 19:00 Last Update: 10-Dec-23 3:04