Yes, you're correct. You can also write: myStruct.app_cb = Foo; I think that's also in the standard rather than being a common compiler extension. Kev

Hi, I'm not having much luck finding information about this but I'm writing an app to dump the file contents of a given MSI. What I'm finding is that when I extract the timestamp by converting the Dos Date/Time data in the FILE_IN_CABINET_INFO structure, I'm off by the timezone difference. I've tried using msidb and cabarc to do the same job and they have the same problem. However, when you install the MSI, the correct (local) time is displayed on the installed file. I'm going with the theory that there's something installed in the MSI itself to allow the correction to be made, but can't find anything to help me. Any pointers greatly appreciated. Thanks. Kev

kakan wrote:

Well... It's pretty hard to to use the SAX API (as I suggested), if the parser in question doesn't support it

Oops, sorry - slipped into work document-reviewing-mode. Comment still stands though ;) K

To be more specific, you want to find a parser that *supports* the SAX API. It isn't SAX exactly, but James Clark's expat supports a similar interface and is one of the earliest and IMO still one of the best XML parsers around. It's certainly very easy to use. You can get this on sourceforge. Kev

Go to the COM and/or ATL section of code project. There are plenty of tutorials there. I've not done a wrapper for this explicit reason, but I've wrapped other DLLs before and its no big problem. The simplest way is to use the ATL Appwizard assuming you're using VC++. Kev

You'll also want to create a new ProgID for the second component, or CreateObject()/new ActiveXObject() won't work. Kev

You're asking one of two things: Q1) how do I create an adjustable-length string to read data into? A - use something like std::vector instead Q2) how do I read in an arbitrary length of user data and minimise the amount of temporary storage required? A - basically, if you don't know in advance how much data there will be, you can only make an educated guess, then shorten the string to the correct size at the end. To keep things to an *absolute minimum*, you read a character at a time and resize and copy the string each new character. However, this is theoretical - it would be dog slow and would probably fragment memory hideously for long message. A common solution is to start off with a buffer (use a std::vector again) and read as many bytes in a chunk from your socket as it would take to fill this. If you've finished reading, stop and shorten your vector. If there's more text, increase the length of the string and read more. You could increase by the same amount (so your string lengths are N, 2N, 3N etc) or double it each time (giving lengths of N, 2N, 4N etc), or any other method. What you want to do is minimise the amount of memory copying and number of socket reads. Hope that helps (homework? :-D ) Kev

You need to declare an instance of class GoGoGo before this will work - i.e.: GoGoGo executesBeforeMain; Kev

To execute javascript you need a script interpreter. You can get this using the ActiveX script host control. However, this is really intended for embedding scripting into your application and is quite complex to use. If your method is simple, you'd be better to simply port it to C++. Alternatively, write your application in javascript? What does C++ bring that you need for your application? Kev

Of the top of my head, can't think of a way in C, but in C++ you can simply use some form of static initialiser. Be warned though, that they can cause problems if not handled correctly. I'd recommend asking yourself if you really need to do this? Kev

Hi Florian, I'm not too sure if I'm fully understanding your problem - it looked at first glance as if it was the same problem as mine. To anyone else reading, if I put my foot in it, please correct me - in no way do I claim to be a COM wizard. Just been around the block a couple of times, learning as I go... X| Basically, if you access a COM component or control using a scripting language, you're limited to whatever functionality is available on the default interface of the component which must be an IDispatch-based interface. Calls are made simply by the scripting host mapping the method or property name (string) onto an id (int) and passing this id along with parameter information to the IDispatch::Invoke method. If your control implements only custom (IUnknown-based) interfaces, you won't be able to access its functionality from a scripting language. If an MFC wizard was used, you'll almost certainly have at least part of your component exposed via a dual interface. If you've added any further secondary interfaces though, these won't be accessible to the scripting language. Can you give me a bit more detail about your component - maybe attach an IDL file or even the coclass definition from the IDL file? Kev

Hi Florian, It may not be related, but at work yesterday, I was having a similar problem when trying to use a legacy C++ OCX from a script. What I found was that the control was written with MFC and was specifically blocking access to the dispatch interface. I was able to override the IsInvokeAllowed() to return TRUE which solved my problem. As I said, it may be completely unrelated, but its worth looking into if your control was written using MFC. Regards Kev

Aha! My foggy brain finally seems to be kicking into gear again. I believe the answer is to: 1) Call CoLoadLibrary() to load the specific DLL into memory 2) Call GetProcAddress() to get the original's DllGetClassObject() function. 3) Call DllGetClassObject() to get the original DLL's class-factory, then off-we-go! Pretty obvious really. Oh well :doh: I'll try this out later on today when shipping-hell lets me. Kev

Hi, thanks for replying - all useful information. However, I don't think I made my question clear enough. What I am trying to achieve is to be able to install my binary-compatible version of an exisiting DLL onto a pre-existing system containing the original DLL. My new DLL would register itself and be the DLL loaded by clients of the original DLL. My DLL, because it knows that there is an existing DLL in a known location would be able to the original to provide the clients with identical functionality. If I was using plain DLL's I'd simply be able to install the new version so that it was found earlier in the path and load in the original DLL using LoadLibrary(). Since I know exactly what the interfaces are, I could do this with the COM DLL. However, I'm looking for an "official" COM way of short-circuiting the registry lookup. Kev

Hi, I'm not sure if this is possible, or whether it's been answered before but I've reached meltdown trying to guess the key phrase to get information on this. What I have is: - an existing COM DLL + idl etc which is installed in location A What I'd like to do is: write a new version of the DLL supporting the same interfaces as A so it is a complete replacement for A. However, I actually want to use the original DLL to do all the work. All the new DLL is for is to journal calls in and events out of the original and forward responses back to the client application. It may eventually multiplex information elsewhere, but that's the future. Any help would be greatly appreciated. I've been staring at MSDN too long to actually read the COM API clearly :sigh: Thanks. Kev