I now have an in-process dolphin COM object running, but the moment I
try to show one of my Shells/views I get an error, the first time it was "Unable to open window" and now its giving me "Common control call failed". Is there some initialisation code I may need to specifically run before using GUIs from an AXDllImageStripper based dll? |
Mark,
----- Original Message ----- From: "Mark Derricutt" <[hidden email]> Newsgroups: comp.lang.smalltalk.dolphin Sent: Wednesday, August 18, 2004 6:18 PM Subject: COM dll showing views? > I now have an in-process dolphin COM object running, but the moment I > try to show one of my Shells/views I get an error, the first time it was > "Unable to open window" and now its giving me "Common control call failed". This is what I ran into, too. Check this Google thread for an overview and some related code: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=aj8d5c%24198k7l%241%40ID-50941.news.dfncis.de&rnum=2&prev=/groups%3Fq%3Dcomp.lang.smalltalk.dolphin%2Bgui%2Bprocess%2Bdll%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3Daj8d5c%2524198k7l%25241%2540ID-50941.news.dfncis.de%26rnum%3D2 The code in that thread needs a couple more modifications related to registering itself (as mentioned in another recent post), but it should be enough to get you started. If you want to wait until I get a chance tomorrow sometime I could send you the code for everything, too. HTH, Don > > Is there some initialisation code I may need to specifically run before > using GUIs from an AXDllImageStripper based dll? |
Don Rylander wrote:
> The code in that thread needs a couple more modifications related to > registering itself (as mentioned in another recent post), but it should be > enough to get you started. If you want to wait until I get a chance > tomorrow sometime I could send you the code for everything, too. I just tried it as it was mentioned but the stripping process seems to fail instantly. I filed in the .cls file and did a deploy, surely that shouldn't cause a nasty ugly system crash? |
"Mark Derricutt" <[hidden email]> wrote in message
news:cg14hb$[hidden email]... > Don Rylander wrote: > > > The code in that thread needs a couple more modifications related to > > registering itself (as mentioned in another recent post), but it should be > > enough to get you started. If you want to wait until I get a chance > > tomorrow sometime I could send you the code for everything, too. > > I just tried it as it was mentioned but the stripping process seems to > fail instantly. I filed in the .cls file and did a deploy, surely that > shouldn't cause a nasty ugly system crash? Make sure you're using the right SessionManager subclass (the new one) and stub file (I use IPDolphinToGo), and be sure to deploy from a fresh image. I did some refactoring the other day and carelessly picked the wrong SessionManager (the regular AXDLL one), and Dolphin had to exit just a few seconds into the stripping process. If the hints in the first sentence don't help, check the ERRORS file. That can often give you some good hints. IIRC, every time I've had a problem deploying, it's been because of some stupid mistake on my part. As far as being an Outlook add-in goes, have you implemented the IDTExtensibility2 interface for your app? If not, that's the next step. In fact it's handy to have it before you even bother trying to deploy, since Outlook can load the development image instead of a DLL when it connects to your application through that interface. Now /that's/ a handy feature. HTH, Don |
In reply to this post by talios@gmail.com
Mark Derricutt wrote:
> I just tried it as it was mentioned but the stripping process seems to > fail instantly. I filed in the .cls file and did a deploy, surely that > shouldn't cause a nasty ugly system crash? If you really mean that you filed it in (rather than installed a package) then the code will end up in all sorts of unrelated packages. Since Dolphin's image stripper removes irrelevant packages as its first step, there's a good chance that code you /need/ will be removed at this stage. -- chris |
In reply to this post by Don Rylander-2
Don Rylander wrote:
> Make sure you're using the right SessionManager subclass (the new one) and > stub file (I use IPDolphinToGo), and be sure to deploy from a fresh image. > I did some refactoring the other day and carelessly picked the wrong Working now, I moved that new class into my own package and that solved the deployment problem. > As far as being an Outlook add-in goes, have you implemented the > IDTExtensibility2 interface for your app? If not, that's the next step. In The plugin is now working fine and I have a button on the Outlook toolbar, had a slight modification to the way I was adding a button. Now my next challenge is responding to events... I've found various posts relating to AXEventSink but the moment I call connect: on my outlook button I get problems. I'm sure I'll get there :) trying the following: sink := AXEventSink target: self sourceTypeInfo: OFficeICommandBarButtonEvents typeInfo. sink connect: myButton. *ponders and googles and tries more foo* |
> I've found various posts relating to AXEventSink but the moment I call
> connect: on my outlook button I get problems. I'm sure I'll get there :) Is the problem merely that it does nothing, or does it actively do something bad? > trying the following: > > sink := AXEventSink target: self sourceTypeInfo: > OFficeICommandBarButtonEvents typeInfo. > sink connect: myButton. Have you registered interest in the events? Something along the lines of self when:#ClearlyDefinedEvent:lpzReserved:lpvoidNotUsed: sendTo:self. should get you going. See #isTracingEnabled:, and note that you need to use the correct event/message name (including case and trailing colon if any) or you will not receive the events. You will want to define the method, even if just a stub, before registering interest in the event. When doing something like this, I like to get everything ready to go but short of doing the dangerous/uncertain step, and then save the image. Upon loading, the image has a workspace with expression(s) ready to go, and if the outcome is unpleasant, I can use the debugger to learn something about it, and exit w/o saving. Reload the image, try to fix the problem, save, then try it again. I that approach any time I change presenter initialization/opening, external interfacing, etc. Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
Bill Schwab wrote:
> self > when:#ClearlyDefinedEvent:lpzReserved:lpvoidNotUsed: > sendTo:self. using sendTo worked, some docs I saw showed using "send: #myMessage to: self" which didn't seem to work ( no send: to: message ). mmm. In any case, the code now seems to be working, now for getting webservices doing there thing ;-) Teething problems abound, but I'm getting there, and its definitiely an interesting switch from the Java I've been doing lately. |
Free forum by Nabble | Edit this page |