Re: Is this a legitimate use of ExternalAddress?

Jeff,

So, I've now got a new object that wraps up the ExternalCallback and
stores it in an instance variable. Simple enough. Now, the first time
the program runs (test from a worksheet), everything is perfect for the
full duration of the test. The second run (ie, hilighting the same test
code and evaluating) results in a GPF, though. Same code, same callback
block.

That definitely shouldn't happen.

On the assumption that you haven't missed anything which needs to be protected
(easy to do until you get into the habit of thinking in C while programming in
Smalltalk), it sounds like a bug in the external library which is holding onto
and using a pointer after it has been told not to (you have told it that the
pointer is now invalid ?).

One quick check would be to execute the:
MyExternalLibrary closeDefault; clear.
incantation -- which should completely unload the external library. If doing
that between two runs of your workspace test makes the problem go away, then it
is almost certainly a bug (or design misfeature) in the external library, or an
omission in the way you are driving it.


I also find it very helpful to work with VC debugging the DLL if at all
possible -- that way you can step right into the external call and
verify that pointers and other parameters that C sees are what you
expect.

I was hoping to avoid doing this (at least for now). I can see the
light at the end of the tunnel (where using Smalltalk could provide me
with great efficiency gains), but the setup getting there (at least for
external interfacing) is causing that light to dim daily. :-(

I think it depends on what you are doing. If you are attempting to connect
directly to some third party's DLL, then running that under VC could be a real
chore (unless they supply it with a working VC debug build project, etc --
which is not the typical case). OTOH, if you are connecting to your own code,
or (as I have done several times recently) to your own wrapper DLL for some
third party's non-DLL library, then it's extremely simple -- just don't exit VC
before you test your code from Dolphin ;-)

Well, OK, it a /little/ more complicated than that -- you have to tell Dolphin
to load the DLL from VC's debug folder, and tell VC to "attach" the Dolphin
process -- but I promise you that it is still pretty painless. In fact it is
rather nice -- it feels as if you are extending at least some of Smalltalk's
dynamic-ness into the static C/C++ world. I have even (just once) got
modify-and-continue to work from C++ while debugging a DLL called from
Dolphin -- the /only/ time in about 10 years that that feature has ever worked
for me...

-- chris


.

Relevant Pages

  • Re: Importing a Class define in a Dll
    ... pointer as an extra parameter passed to each non-static ... It is specially useful for the ARM platform as the ... MyClass() {... ... Build the DLL containing your class in the same ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: Exception handling for loading of dependency library?
    ... typedef int (const CString & s, ... A common technique for doing this is to declare it as a global variable, ... the handle for a given dll all in one place. ... pointless because ANSI C does not require dereferencing function pointer variables. ...
    (microsoft.public.vc.mfc)
  • Re: How to program plugin DLLs
    ... build the descriptor you mentioned. ... That class is the "only" element to be exported from the DLL. ... pointer to that class and then call something like this: ... > What I might consider here is a method which fills in a popup menu. ...
    (microsoft.public.vc.mfc)
  • Re: Pointers and DLLs/shared libraries
    ... These pointer variables will point to data in the main program. ... subroutine set_pointer ... (DLLs and shared libraries do not always behave like ordinary ... ....the DLL effectively becomes a part of all of the client programs that use it. ...
    (comp.lang.fortran)
  • Re: dll load address
    ... Marco Ventanas ... >> I'm trying to read the dll import table using a pointer initialized to ... >> but as I read the first byte pointed by this pointer, ... but the displayed Base Addr is the same for all ...
    (microsoft.public.windowsce.platbuilder)