reading STB data when opening an applet

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

reading STB data when opening an applet

Ted Bracht-2
Hi,

I'm trying to read data when opening an applet in a web page, but the
standard DocumentShell>>fileLoad doesn't seem to work (my shell is a
subclass of DocumentShell). I've got it all on my local machine, but even if
I provide the full path, it still doesn't load. I seem to be missing
something here.

The application works ok if I just create a new model.

Hope someone can help,

Thanks,

Ted


Reply | Threaded
Open this post in threaded view
|

Re: reading STB data when opening an applet

Bill Schwab
Ted,

> I'm trying to read data when opening an applet in a web page, but the
> standard DocumentShell>>fileLoad doesn't seem to work (my shell is a
> subclass of DocumentShell). I've got it all on my local machine, but even
if
> I provide the full path, it still doesn't load. I seem to be missing
> something here.
>
> The application works ok if I just create a new model.

Can you say more about how/why it fails to load?  A crash dump, call stack,
or anything you can capture in a debug monitor (see www.sysinternals.com for
a nice monitor app)  would be helpful.  Have you tried debugging the applet,
and does it work at this point?

The most common problem I've seen in my limited experimentation with applets
has been that required classes were not present in the image.
Unfortunately, it's not immediately obvious from the dump, though Blair
posted some instructions for how to find the missing class name in a
resulting crash dump.  You might find that the solution is as simple as
saving another binary package and making it available in the same directory
as your current binary package.

Have a good one,

Bill

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


Reply | Threaded
Open this post in threaded view
|

Re: reading STB data when opening an applet

Ted Bracht-2
Hi Bill, thanks for your reply.

>
> Can you say more about how/why it fails to load?

After the DolphinSure dialog a Warning messagebox comes up with the
following message:
'UndefinedObject doesn't understand #,'
After pressing OK on that warning, another Warning messagebox comes up with
message:
'PluginSessionManager doesn't understand #,'
After pressing OK on that warning, an Error messagebox opens:
'Invalid arg 3: Cannot coerce a PluginSessionManager to lpstr'

If I open a view on a new model, it all works ok. If I then try to read an
existing model, the same error occurs (opening a FileOpen dialog).

If I open a view on a new model, and save it on my local disk then I can
open it later on in the same app running in the development environment.

The model is dead simple just a couple of dates and two lists.

The only thing I can think of is that the view is a subclass of
DocumentShell which the PluginSessionManager might not like very much?


> A crash dump, call stack,
> or anything you can capture in a debug monitor (see www.sysinternals.com
for
> a nice monitor app)  would be helpful.  Have you tried debugging the
applet,
> and does it work at this point?

I'll give that a try as well

>
> The most common problem I've seen in my limited experimentation with
applets
> has been that required classes were not present in the image.
> Unfortunately, it's not immediately obvious from the dump, though Blair
> posted some instructions for how to find the missing class name in a
> resulting crash dump.  You might find that the solution is as simple as
> saving another binary package and making it available in the same
directory
> as your current binary package.

As I'm only using standard Dolphin classes, that would mean moving them out
of the Dolphin package.

Ted