More on blocks

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

More on blocks

Bill Schwab-2
Blair,

One more dumb question about blocks: I have a way to recreate/collect large
numbers of STB-captured blocks, and I'm finding that all of a particular
type/origin tell me that their source is currently unavailable.  It's not a
big deal because I know the method that created them, and that will
(hopefully<g>) be enough to create alternative objects.  However, it would
be reassuring to get a little more proof, so I'm wondering whether there are
any likely silly mistakes or other things that could cause the source not to
be found??  The method in question appears to exist in the image.

Perhaps relevant is that I'm doing this in D5, and the blocks were created
by a D4 deployed exe.

Have a good one,

Bill

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


Reply | Threaded
Open this post in threaded view
|

Re: More on blocks

Blair McGlashan
"Bill Schwab" <[hidden email]> wrote in message
news:aelbsp$7sasf$[hidden email]...
> Blair,
>
> One more dumb question about blocks: I have a way to recreate/collect
large
> numbers of STB-captured blocks, and I'm finding that all of a particular
> type/origin tell me that their source is currently unavailable.  It's not
a
> big deal because I know the method that created them, and that will
> (hopefully<g>) be enough to create alternative objects.  However, it would
> be reassuring to get a little more proof, so I'm wondering whether there
are
> any likely silly mistakes or other things that could cause the source not
to
> be found??  The method in question appears to exist in the image.
>
> Perhaps relevant is that I'm doing this in D5, and the blocks were created
> by a D4 deployed exe.

Well there is your answer: No method source exists in a deployed
application.

A little explanatory background: All method source is held in external
source files (usually just Dolphin.chg and Dolphin.sml), with the methods
holding a "pointer" to the location of their source in these files. Compiled
expressions actually hold their source as a string, so the source for these
is carried around with the object - including when binary filed.

Regards

Blair


Reply | Threaded
Open this post in threaded view
|

Re: More on blocks

Bill Schwab-2
Blair,

> > Perhaps relevant is that I'm doing this in D5, and the blocks were
created
> > by a D4 deployed exe.
>
> Well there is your answer: No method source exists in a deployed
> application.
>
> A little explanatory background: All method source is held in external
> source files (usually just Dolphin.chg and Dolphin.sml), with the methods
> holding a "pointer" to the location of their source in these files.
Compiled
> expressions actually hold their source as a string, so the source for
these
> is carried around with the object - including when binary filed.

Would there be a way to match up to the code in the development image?
Obviously things could have changed since the block was created and
serialized, so I'd expect to have to maybe match up byte codes or something.
Would the idea be to use the class and method name to locate the code in the
development image, use the initial IP to select the code and somehow
cross-check the byte codes?

If it's just plain hopeless, that's ok.  I can probably fix the "damage"
without such a tool, and hope to eliminate my dependence on serialized
blocks going forward.

Have a good one,

Bill

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