I have a CAB file which has a COM DLL and .INF file. My application is embedding this component in a JSP page and it is working fine in IE7 & IE8 but failed to work on IE9.
Any suggestion on how to solve this issue
Where can I get books on ActiveX and COM. I started with an ActiveX book (ATL) and it began by stating I must know COM. I wound up with Dale Rogerson's "Inside Com" Its on Amazon but no soft copy. I don't want any more hard copy books.
Every where I find a PDF or ebook version they want me to first down load their downloader. Their code could have anything in it so: No! to that.
So: What books do you recommend to a novice that needs to write an ActiveX component. The container is a commercial product and I need to write a video display for some very custom video input.
I am happy to pay, but it must be a soft copy.
Thanks for your time
EDIT: Another book I need: Win APIs. The APIs and method that are needed to directly use TPC/IP. I want the ability to bypass all the cycle stealing intermediate classes and go directly to the API. I am having a difficult time with my searches on this and prefer a book that someone recommends rather than a stab in the dark.
You mentioned Inside COM by Dale Rogerson which remember using so I had a glance at my bookshelves. I know Inside COM taught me the underlying principles of interfaces and COM without resorting to ATL or MFC. Professional COM Applications with ATL (Wrox, 1999) was quite good on Active X, and does have a section 'Building an ActiveX Calendar Control' which explains a lot. However something like this, whilst being the same era as Inside COM, refers to VC6 and ATL3, not the most up to date now. I did also buy ActiveX Controls Inside Out (Microsoft Press, 1997) and see it on my shelf but this is un-thumbed so I obviously didn't use it a lot, but its more wider ranging than the ATL book mentioning MFC and Visual Basic controls (VBXs). I don't want to sell mine but hope this might help.
While launching a windows application(.exe) as OLE server, some time CWinApp::OnFileNew() gets failed; due to this handle to the main window (m_pMainWnd) becomes NULL and error message "Error related with mfc42.dll occurred" appeared.
At windows XP, CWinApp::OnFileNew() failed in 1 out of 100 times.
We have not implemented the OnFileNew() in our application; we are using default implementation of OnFileNew().
As per MSDN CWinApp::OnFileNew implements this command differently depending on the number of document templates in the application. If there is only one CDocTemplate, CWinApp::OnFileNew will create a new document of that type, as well as the proper frame and view class.
Problem occurs only at one system and frequency is one out of 100 and error message "Error occurs in mfc42.dll" appeared.
Environment Windows XP Pro, Visual Studio 2008, MFC, C++
This application processes real time telemetry data. The first incarnation uses blocking TCP calls and works fine. It is just difficult to deal with due to the blocking calls.
The second implementation uses CAsyncSocket. After much work I discovered that it can keep up when about 1/3 of the data is processed. It cannot keep up with all the data.
I say that with some level of confidence because the code monitors the depth of the buffering queue. Since the telemetry data never stops, at the TCP/IP level, when it receives the WSAEWOULDBLOCK error, it buffers payload packets until it get the OnSend. At the one third data rate the max buffer fill level is 91 payload packets. At the full rate the buffer, currently 240 deep) overflows, frequently. My next step might be to go to the Win32 API level.
I started with MFC because the vendor whose software feeds me the data provided an MFC template that showed how to get data from their application. It was written in Visual Studio 2008 MFC. During real time operations it does no user interactions and no GUI updates.
Or, I maybe I should just abandon the asynchronous effort due to a combination of too much effort, too litle return, and maybe even not possible.
Drawing on the reader's experience, and on Richard MacCutchan's response in my previous thread, and with a packet rate well in excess of 10 per millisecond:
What is the probability of success if I switch over to the Win32 API programming. Switch to a console application? Is the asynchronous code inherently less efficient, or is this more likely a problem using the CAsynchSocket class. (I presume it looses efficiency in the tradeoff for ease of use.) Or maybe an MFC problem, or combination thereof.
Right now I am leaning towards abandoning the asynchronous effort and just use the blocking code that works well. I would like to hear your thoughts.
Thanks for your time
Last Visit: 31-Dec-99 18:00 Last Update: 29-Jul-14 22:29