I'm replying to two threads at the same time and cross posting my reply, because they are very relevant to each other. I'm sorry if anyone here ends up seeing this more than once as a consequence. [s] ------

Sarah

Did you get this problem sorted out?

Not directly. I ended up building an 'outer' COM component in C++ that mapped an MSXML-like interface onto a simpler, internal COM component that wraps up the Haskell code. This approach seems to work well - I might have been able to build the necessary wrapper directly in Haskell using HDirect, but I was becoming aware that I was probably starting to take up an unreasonable amount of Sigbjorn's time with increasingly detailed questions and I didn't have time to figure out the necessary intricacies from scratch. HDirect seems very good, but I don't think it's currently in quite as stable a state as the main GHC release. The problems I had in building a version that works with the current GHC are an example of this. I'm not complaining - it worked well in the end, but I do think it might be a 'good thing' to consider rolling HDirect into the main GHC release at some point. The other thing that bit me was exception handling, or rather the default behaviour when an uncaught exception 'falls out' and reaches the top level of the runtime system. Currently, the functionality appears to be to abort the current process. Whilst this is probably desirable for a typical application executable (be that console or GUI based), it is a problem if it happens inside a COM component. My thinking is quite straightforward on this. Preferred behaviour should really be for a call to a COM component to fail returning an error code, rather than abort the calling process. 'Server-style' applications are usually expected to keep running when minor faults occur, rather than terminate. HDirect/GHC's current behaviour makes this difficult to achieve - I managed to successfully catch exceptions, but the price was needing to use some code based on DeepSeq to force deep strict evaluation for all state updates. This (seemingly) was the only way I could stop exceptions from happening in the context of the automatically generated COM wrapper - passing it a fully evaluated data structure was apparently the only solution available. However, this does break the advantages of laziness as applied to the current state of the object - it would be pretty neat, for example, to be able to define a view of a database as the result of an expression involving relational algebra combinators, with the query evaluated one record at a time as the data is pulled back by the client application. The need for DeepSeq forces strict evaluation, so this benefit is lost. This is actually more of an issue than it might immediately seem - many queries don't actually need to retrieve all of a record set before useful things can be done. A particular example is updating a GUI, where a list box reflects the results of a query. Lazy evaluation will allow the screen to start updating more or less immediately even on a query that returns thousands of records - strict evaluation might incur a delay of a few seconds (for a very complex query or a large database) before updates can start happening. In an ideal world, what I'd dearly love to see would be an HDirect option that allows a choice between existing functionality and having calls return a failure code, or better still allowing a user-supplied handler function to determine the correct course of action. So, to sum up my wish list: 1. A facility to replace the default uncaught exception behaviour for COM objects and similar shared library code 2. HDirect rolled into the main GHC tree 3. A facility within HDirect to create COM objects based on existing (Haskell) data structures, returning an interface pointer as a return parameter on a call to an existing COM object. (This was the question Simon asked if I'd had an answer to - I've attached a copy below for reference). Sarah PS: I've not yet looked closely at the .NET integration in GHC yet, but I can imagine myself having a very similar wish list in that case too. -------- Hi again, A slightly harder problem this time. I want to implement something that looks something like the Microsoft XML parser. This is a very COM heavy contraption that provides an interface that looks to client applications like a tree of COM objects that reflects the internal structure of an XML document. The idea is, you start with the document object, make a method call requesting the root node, and have a COM object that wraps that node returned to you. You can then request the children of that node, and their children and siblings, all which involves being passed back interface pointers to COM objects. Effectively, there is one COM object per syntactic item in the XML document. I already have my document object working nicely. This is where the actual database resides. I want to be able to spawn views of this database as COM objects. When I've done this in the past (using ATL mostly, euuuugh), I've used an IDL definition something like HRESULT CreateView([in,string] BSTR query, [out,retval] IDbView **); What's the correct way to implement the necessary Haskell code to create the coclass and return a pointer to it? I fiddled around for ages, but either couldn't get GHC to like the types I was using, or when I finally got it to compile, I found that my test harness was being passed an invalid COM object. This should be simple stuff, so I'm sure someone will have done it! Secondly, it is a nasty, though fairly common trick, if you know your objects are going to be created in the same process space, to allow them some 'behind the scenes' communication. In my case, I'd like to avoid needing to serialise and deserialise the data in a view during creation of these child objects (of which there may be a great many, and which may be created on the fly rather often). Ideally, I'd like to be able to do something like: newView :: String -> State -> IO State newView db (State st) = do db <- readIORef st r <- newIORef db -- Insert some kind of COM magic here return (State r) so the database content gets copied within the Haskell environment (lazily, I'd hope), without needing to be serialised and deserialised. Is this feasible? One (messy) approach might be to create a bunch of extra interfaces on the main database object, then create 'thin wrapper' child objects that simply make calls back into the parent object. I'm not so keen on that for various reasons, however. Sarah