|
If you've #imported the typelib then you can add the import directive named_guids to the import statement.
Then you will find the IID in the .tlh file.
Otherwise you could marshal the IDispatch interface, unless you're using the v-table part of Excel's dual interfaces. Just use IID_IDispatch as REFIID.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
|
|
|
|
|
That Just gives me an IID_IDISPATCH undeclared identifier error. I have a thread that I want to be able to cancel and then allow the primary thread to save the excel file and quit the excel application. I searched my entire disk for *.tlh and found no files.
void C65602::RunTestThread()
{
DWORD result;
HRESULT hr;
hr = CoInitialize(NULL);
pTests->pOutput->OpenWorksheet();
pTests->pOutput->OutputMainHeader();
CoMarshalInterThreadInterfaceInStream(IID_IDISPATCH, NULL, &pStream); // IID_IDISPATCH ERROR HERE
... DO THREAD PROCESSING ...
CoUninitialize();
AfxEndThread(0, TRUE);
}
void COutput::OpenWorksheet()
{
m_App.CreateDispatch("Excel.Application");
}
|
|
|
|
|
BuckBrown wrote: That Just gives me an IID_IDISPATCH undeclared identifier error
IID_IDispatch, not IID_IDISPATCH. C/C++ identifiers are case sensitive.
What do you intend to do in your thread and why do you think you need a threading solution?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
|
|
|
|
|
Sorry yeah,
I have tried to declare this various ways (depending on the sparse examples I'm looking at)
IDispatch dispatch;
IID_IDispatch dispatch;
DISPID dispatch;
LPDISPATCH dispath;
None of them work the way I want. It either compiles and does not work or it fails to compile because it cannot convert IDispatch* to __GUID*. I have tried casting but havent found one yet.
I am looking at trying m_App->lpDispatch->QueryInterface() function. There are a couple of reasons why I want a secondary thread. The secondary thread might take from 10 minutes to over an hour. I wanted a way to allow the user to cancel the test from the same user interface (in this case a tab page) that launched the test. The secondary thread can create and output to an Excel file and then save the file and quit the Excel automation before it dies. If the user clicks on the 'Cancel Test' button I want the primary thread to perform the save and quit. This is why I need to marshal the interface pointer out of the secondary thread and get it from the primary thread.
|
|
|
|
|
Ok...
First, a couple of suggestions and things to consider:
1. I'm a little suspicious about your reasons for using a second thread. You're performing some kind of tests from your secondary thread. How do you know when a test has finished and what the result of the test was? Perhaps this could be done from the primary thread, it depends on how your tests works. I'm not saying that it's wrong, I'm just saying "think about it because it will save you a lot of trouble".
2. To me it would feel more natural if the primary thread was responsible for launching Excel as out-of-process automation server. I suspect that you should get a filename from the user which requires interfacing with the GUI and that shall always be done from the primary thead. It's also a common guideline for each thread that creates COM servers to process messages. In your case the Excel proxy would reside in your secondary thread which I suspect doesn't process messages. If you launched Excel from your primary thread, then you would have the message pump for free. 
3. If you continue with your solution to launch Excel from your secondary thread and let the primary thread do the saving stuff to Excel, it won't work if your secondary thread doesn't process messages. You risk facing a nasty deadlock if you try to exit your thread, calling ::CoUninitialize(), before the primary thread has released its interface to Excel. This is because the RPC service, which handles the marshalling between apartment boundaries, sends messages to the proxies and stubs in the different apartments. Sending a message means to wait until the receiving thread has processed the message and if it doesn't your sending thread will deadlock.
Now for how to set up the marshalling and the use of IID_IDispatch:
Declare an IStream* variable in your class. This is going to be used when you're calling ::CoMarshalInterThreadInterfaceInStream() and ::CoGetInterfaceAndReleaseStream().
The code from which you marshal an interface would look something like this:
HRESULT hr;
hr = ::CoMarshalInterThreadInterfaceInStream( __uuidof( IID_IDispatch ), lpDispatch, &m_stream );
if( FAILED( hr ) )
{
}Now the lpDispatch interface is ready to be fetched from another thread.
The code in the other thread would look something like this:
HRESULT hr;
IDispatch* lpDisp;
hr = ::CoGetInterfaceAndReleaseStream( m_stream, __uuidof( IID_IDispatch ), (void**)&lpDisp );
if( FAILED( hr ) )
{
lpDisp = NULL;
}Now you have a marshalled IDispatch interface.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
|
|
|
|
|
Thanks for the input. I have printed it off for my binder. The __uuidof cast is completely alien to me. In the meantime I have decided to try this with a UI thread. The reason I'm trying to do this with a thread is basically to learn how to use threads. So far I have not been very successful at it. So now I have a user interface thread but it has a few problems of its own when it needs to display a dialog box (application crashes). I will post this problem as something new.
Thanks again.
Buck
|
|
|
|
|
|
 I want to create an application that has 5 dialog type windows in an SDI format. I need the dialog tabs so that the user can click on the different dialog window tab. Furthermore, I can not have any two dialog boxes visible at any one time.
Using the project wizard, I chose an SDI application and created 5 dialog boxes. I used InitDialog to maximize each Window.
Unfortunately, only the active dialog window shows. I can't see the other four windows in a tab-type style.
What am I doing wrong?
|
|
|
|
|
I'm not sure, but see if this[^] sectin helps you.
|
|
|
|
|
You could also use a CDialog based application and insert a CPropoertySheet as the main window.
Hope this helps.
|
|
|
|
|
Make your view derived from CFormView and add a tab control to it.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Hopefully somebody can help me with this problem. I am fairly new with socket connection. I know you guys will want to see some code but unfortunately this is hard to do as my code is on a classified system. I would prefer not to have to type all the necessary code. However if I have to I will.
I have a server-client socket connect and I use CSocket. Once the connection is made, the server sends 168-byte message to the client once per second. In the client OnReceive function I read the data and then write it to a file. In the OnIdle function of the client I also check if the connection with the server is still up by sending a one-byte message to the server. My problem is that it works for a while and then the client OnReceive stops being called by the framework.
Using debugging I know for a fact that the server is still sending the 168-byte messages every seconds without any errors. I also know that the client is still sending the one-byte message to the server and the server is still receiving it. Both programs seem to be working just fine except for the fact that the OnReceive is no longer being called and therefore I am no longer writing data to the file.
Anybody can help me? Thanks!
BTW it never stops at the same place. I can sometimes receive 2K but other times I can receive a lot more. The most I got was 94,168 bytes.
-- modified at 13:41 Tuesday 6th February, 2007
jpyp
|
|
|
|
|
Hmmm sockets have been around for 24 years and you're using CSocket - classified socket code? 
Just teasin.
Anyway, is the protocol TCP?
If you are using OnIdle(), what are you returning from it?
Does it perform better if you move the mouse around occasionally?
Mark
|
|
|
|
|
One other question - Are you pausing your app's main (user interface) thread anywhere, with
Sleep() or a loop? This will prevent the necessary message handling by CSocket which it relies
on to make the OnReceive() call.
Mark
|
|
|
|
|
|
Cool! That's a good one
When you go to higher tranfer rates I'd recommend using CAsyncSocket and/or Sockets APIs and using
WSAEventSelect instead of WSAAsyncSelect. Much better performance and you have complete control
over the events. You can either
a) recv() until there's no more data and go back to waiting for an FD_READ event, which will
occur when more data is in the socket's receive buffer. Or...
b) recv() a certain amount of bytes and go back to waiting for an FD_READ event. If more bytes
are available for receiving then the FD_READ event is set immediately after the last recv() call.
Thank you for the update!
Mark
|
|
|
|
|
The basic advice is that you should make exactly one single call to Receive (which calls the underlying winsock recv() function) from inside your OnReceive function (which the MFC framework calls in response to an FD_READ notification).
This advice can't be found in the MFC documentation, either for CSocket or for CAsnycSocket.
It's found, however, in the documentation for the underlying Winsock functions. For example, see the documentation for WSAAsyncSelect() (which is the Winsock function that causes Windows-style messages to be posted to your application from the network stack) at http://msdn2.microsoft.com/en-us/library/ms741540.aspx[^], which includes this quote:
MSDN at WSAASyncSelect wrote: With these semantics, an application need not read all available data in response to an FD_READ message — a single recv in response to each FD_READ message is appropriate. If an application issues multiple recv calls in response to a single FD_READ, it can receive multiple FD_READ messages. Such an application can require disabling FD_READ messages before starting the recv calls by calling WSAAsyncSelect with the FD_READ event not set.
The point of this is to suggest that you get closer to the Winsock API when you start programming for high-rate transfers. There a a few dozen of these "gotcha's" that you don't learn/know about when using the MFC classes, particularly the CSocket class. Personally, I would avoid CSocket. CAsyncSocket is fine, since it's reasonably close to the Winsock API, but you still need to understand the underlying API if you expect your program to work correctly.
Mike
|
|
|
|
|
Thanks a lot to both of you for your advice. I will definitely take them under consideration when I move to high-rate transfers.
jpyp
|
|
|
|
|
Is it possible somehow to derive several classes from a singleton class? Or would it be better to just create a global singleton and create an instance whenever required?
I want to create some sort of logger class, which would write the errors/logs to a file and optionaly display a dialog. The obvious place for such a class would be the top of the heirarchy. But in my case some classes are derived from multiple others.
|
|
|
|
|
I don't see exactly what you are trying to do... What is the exact 'scheme' that you are trying to get ?
Could you explain a little bit more in detail ? (Maybe with some code example).
|
|
|
|
|
It goes like this. I have a rather large collection of classes, all intertwined with each other. There is only one class at the bottom of the hierarchy, but it branches out towards the top. Now an error could happen anywhere within this structure. When one does happen I need to be able to log it to a file, and/or display it to the user. Currently All my error codes are HRESULTs and I have created a simple macro to pop-up a dialog box thinking I would just change the macro when it comes to dealing with the errors in the proper way.
I don't want to have to open a file, seek and write everytime I need to write to it; so I'm thinking of creating a static class which would map the file to memory and keep it open for the duration of the process. Obviously it would need to be a singleton due to the number of classes which need to access the file. But I can't think where to place such a class in this hierarchy.
|
|
|
|
|
I still don't understand fully your problem. Why don't you have a logger class which is completely 'external' to your class hierarchy. This class is simply a singleton and you can initialize it once at the startup of your program. Then, each time you need it, you get the singleton instance and call a function that log text.
BTW, as we speak about singleton, I suppose that you are refering to the singleton design pattern right (and not just a simple global instance) ? So, in that case, you really don't need to 'place' your class somewhere.
|
|
|
|
|
Cedric Moonen wrote: I suppose that you are refering to the singleton design pattern right
Yes I am.
I was just thinking the same as what you suggested. I was worrying about having an open handle to a file, but I wasn't thinking that with a singleton the c'tor and d'tor are only called once. I could even implement reference counting.
Why ain't I thinking straight tonight...
|
|
|
|
|
WalderMort wrote: I was worrying about having an open handle to a fil
Well, you don't need. If you provide the filename of your file at the startup of your program, you can still keep it as a data member of your class and then reopen the file (in append mode) to log the new message.
(If you are interested, I can post a very simple singleton logger class that I did).
|
|
|
|
|
Cedric Moonen wrote: (If you are interested, I can post a very simple singleton logger class that I did).
Thanks for the offer, but I would prefer to have a dab at it myself.
Cedric Moonen wrote: reopen the file (in append mode)
I was thinking more along the lines of mapping the file to memory. Due to the nature of the program, I would have to divide the file into sections ( OS version, DLL versions, Errors, Bank account numbers..  ) anyway you get the meaning.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
