UserLibrary bug

I'm not positive this is a bug in Dolphin. I have an application that is
basically headless that connects to  another application via a DLL. It
does, however, have a UI when a use has to configure it (triggered by a
callback form the app I'm talking to).
For my SessionManager, I basically made a duplicate of
AXDllGUISessionManager with a method main and keepAlive.
When the app gets a DNU error and attempts to open a messagebox, the
message box routing throws a DNU, which wants to open a message box
which...etc.  The errors file was 250MB before I realized something was
wrong ;)

In UserLibrary messageBox:text:caption:style:icon:instance:
on this line: ifFalse: [anExternalHandle ifNil: [UserLibrary default
getActiveWindow]]

getActiveWindow returns nil to hWnd which, when used later as a
parameter to MSGBOXPARAMS>>hwndOwner results in:

{09150410: cf 091503F1, sp 09150424, bp 0915040C, ip 4,
Object>>doesNotUnderstand:}
        receiver: nil
        arg[0]: Message selector: asInteger arguments: ***Bad Array: 00000000

{091503F0: cf 091503C9, sp 09150404, bp 091503E4, ip 10,
ByteArray>>retryDwordAtOffset:put:}
        receiver: a ByteArray
        arg[0]: 4
        arg[1]: nil
        stack temp[0]: nil

{091503C8: cf 091503A5, sp 091503DC, bp 091503C0, ip 4,
ByteArray>>dwordAtOffset:put:}
        receiver: a ByteArray
        arg[0]: 4
        arg[1]: nil

{091503A4: cf 09150385, sp 091503B8, bp 091503A0, ip 6,
MSGBOXPARAMS>>hwndOwner:}
        receiver: a MSGBOXPARAMS
        arg[0]: nil



Is this a legitimate bug or is the method I used for a headless app the
problem?


Take care,

John

I forgot to include my other question...
I temp-fixed that by checking the getActiveWindow return for nil and
returning a 0 instead. How does one handle temp fixes such as this?
Should the "fixed" method be moved to my apps package or left in the
Dolphin package? My guess it that I move this to my package so the
change is there when I install the package in a fresh image for
deployment. I'm guessing that I will get that "method already
exists...replace it" message when I install the package.
The other option I was thinking of was to make a new separate
"JohnsPatches" package to be gotten rid of when a new version comes out.

Thanks,

John

John wrote:

> When the app gets a DNU error and attempts to open a messagebox, the
> message box routing throws a DNU, which wants to open a message box
> which...etc.  The errors file was 250MB before I realized something was
> wrong ;)

This seems to be a bug in D6.  A couple of other people have reported being
bitten by it too -- see the 'Dolphin X6 ToGo crash with dodgy .ERRORS file'
thread.


> How does one handle temp fixes such as this?

What I do is to create a small package for each fix.  That package contains
both the fixed form of the method(s), and the original (with a name like
xxx_ORIG) so that I can compare the version in the base image (after patching)
with what I /think/ needs fixing.

Those packages are never uninstalled, they get added to my base image as I
build a new one, and similarly to the clean image I use for deployment.  So I
have to click a lot of OK buttons while I'm rebuilding either image, but I
don't do that often, so it's not a problem.

No doubt other people have other ways of handling such patches, but the above
works for me.

BTW, in case you haven't realised yet.  You can use Ian's Chunk Browser to
compare the contents of a .PAC file, or a file-out file, with what's currently
in the image -- which is very handy...

    -- chris

John,

FWIW, I mark such methods with selectors such as #wksSafe and
#wksDangerous, and have my image setup tool (Migrate) displays them when
setting up the new image.  I have not ported the tools to D6, but the
idea is easy to apply.  It avoids problems of clashing or overwriting
the new environment, or at least, puts the decision in the hands of the
programmer loading the packages in the new system =:0

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"John" <[hidden email]> wrote in message
news:ROKTf.8307$[hidden email]...
I think its a bug because it will effect Message Boxes shown for unhandled
exceptions that occur on background threads. We'll fix this in the next
patch level. Thanks for the report.

However, for your own message boxes it is not recommend that you use this
method. It is private, and therefore subject to arbitrary removal (i.e.
without deprecation) or modification in subsequent releases. You should be
using the MessageBox class instead. MessageBox itself does not suffer from
the bug.

Regards

Blair

Thanks Bill. I'll have a look at it. Though if that programmer was me, I
still agonize over those types of decisions ;)

A Quick thanks as well. I've had success with your EZ-TWAIN package.
Definitely saved me a big hassle!

Enjoy the rest of our freezing Florida window,

John

Chris Uppal wrote: Ah, I had missed Steve's reply describing the exact problem/solution.

I was thinking of something like this. I was wondering how you sorted
this all out when a new patch from OA comes out since when loading a
package forces you to overwrite what is in the image or abort loading?
Is this where you would use Chunk Browser?

> BTW, in case you haven't realised yet.  You can use Ian's Chunk Browser to
> compare the contents of a .PAC file, or a file-out file, with what's currently
> in the image -- which is very handy...
>
>     -- chris
>
>

Oh yea. That gem has saved my behind numerous times since starting with
Dolphin. I'm sure if we were keeping track, I would hold the record for
most screwed up images per month ;)

Take care,

John

John wrote:

> > What I do is to create a small package for each fix.  That package
> > contains both the fixed form of the method(s), and the original (with a
> > name like xxx_ORIG) so that I can compare the version in the base image
> > (after patching) with what I /think/ needs fixing.
[...]
> I was thinking of something like this. I was wondering how you sorted
> this all out when a new patch from OA comes out since when loading a
> package forces you to overwrite what is in the image or abort loading?
> Is this where you would use Chunk Browser?

Yes, the Chunk Browser is the main tool, if I'm not sure which of my fixes are
still needed.

One thing I didn't mention is that I don't apply patches to my working image.
I go back to a clean image, apply the OA patches, and then apply which ever of
my fixes are still needed.  That gives me a clean base into which I can load
whatever "real" packages I want to work on or deploy.

    -- chris

John,

> Thanks Bill. I'll have a look at it. Though if that programmer was me, I
> still agonize over those types of decisions ;)

Re the safe/dangerous stuff???  A little agonizing is a good thing in
such cases - just don't over do it :)


> A Quick thanks as well. I've had success with your EZ-TWAIN package.
> Definitely saved me a big hassle!

Great!


> Enjoy the rest of our freezing Florida window,

It will "unfreeze" and then some all too soon =:(

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

John wrote:
> A Quick thanks as well. I've had success with your EZ-TWAIN package.
> Definitely saved me a big hassle!
Did you consider using M$s "Windows Image Acquisition Automation Layer"?

I found it pretty easy to use. And it's not limited to TWAIN Scanners
but can access all sorts of digital devices (e.g. video and photo
cameras) as well.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wiaaut/wia/wiax/overviews/startpagewiaaut.asp
http://msdn.microsoft.com/coding4fun/someassemblyrequired/lookatme/default.aspx
http://www.codeproject.com/dotnet/wiascriptingdotnet.asp

CU,

Udo