(no subject)

Greetings All,

I recently built a small ToGo app which read some data from a web-server in
#onViewOpened. It worked fine in the development image, but exited almost
instantly when packaged as a ToGo stand-alone.

The .ERRORS file contained:

    {0712038C: cf 07120371, sp 0712039C, bp 07120388, ip 4,
WebFileCheckerSessionManager(SessionManager)>>onUnhandledError:}
     receiver: a WebFileCheckerSessionManager
     arg[0]: a SocketError

Eventually worked out, and confirmed by Steve Waring, that I was trying to
communicate before the sockets infrastructure was started. I hacked my way
around it by forking the communications at system background priority from
within #onViewOpened. (Actually doing the communications within
#onViewOpened was too early).

So it works fine, but relying on process priority seems non-determinate &
may cause grief at some unknown future time. Is there any way we could
structure startup of communications so it triggered an event like
#socketsStarted or such?

Any reccomendations?
Regards,


--Peter Goodall

shouldn't be allowed out on my own...

"Peter Goodall" <[hidden email]> wrote in message
news:3fb49ee1$0$13680$[hidden email]...
> Greetings All,
>
> I recently built a small ToGo app which read some data from a web-server
in
The sockets package was designed and implemented in the early days of
Dolphin, and does not follow the external subsystem lazy initialization
pattern that we established later, i.e. rather than calling WSAStartup (the
call to initialise the wnisock subsystem) on demand when the default
instance of WSockLibrary is opened, it initialises itself in a hard-wired
way by hooking into the mechanism intended just to clear down old
ExternalLibrary instances during early system startup. In fact this is far
too early on, and means that the system will completely fail to start if
there is any problem calling WSAStartup. It is too early to open a debugger
and the system will just crash. This has already been revised for D6 so that
the initialisation occurs lazily.

The thing I find a bit odd about this is that the hard-wired startup means
that the sockets subsystem is initialised very early on in startup
processing, way before any windows are actually opened. Therefore I don't
understand how your error could be arising.

It is safe to call WSAStartup multiple times, so I would suggest that you
try inserting a call to WSockLibrary class>>startSocketSystem in your
#onViewOpened, and a call to WSockLibrary class>>onExit in your
onViewDestroyed. This will prove if the problem is related to attempting
operations before the socket subsystem is initialised. I suspect you will
find that it makes no difference, because as I say the WSAStartup call
occurs very early on.

Regards

Blair

Hi Blair,

"Blair McGlashan" <blair@no spam object-arts.com> wrote in message
news:3fb89c3e$[hidden email]...
> "Peter Goodall" <[hidden email]> wrote in message
> news:3fb49ee1$0$13680$[hidden email]...
> > Greetings All,
> >
> > I recently built a small ToGo app which read some data from a web-server
> in
> > #onViewOpened. It worked fine in the development image, but exited
almost
> > instantly when packaged as a ToGo stand-alone.
> > ...[snip]...
> > Eventually worked out, and confirmed by Steve Waring, that I was trying
to
> > communicate before the sockets infrastructure was started. I hacked my
way
[...]
My apologies - I took Steve's name in vain here, not undestanding at that
stage what he meant.
Steve suggested that the socket system was being shutdown while I was
communicating
- because a new main process was being forked,  and that this new main
process shut down
because it didn't find any open windows. So, my communication with the
server took long enough
to cause the main process to infer a problem and shut down.
[...]
> The thing I find a bit odd about this is that the hard-wired startup means
> that the sockets subsystem is initialised very early on in startup
> processing, way before any windows are actually opened. Therefore I don't
> understand how your error could be arising.
[...]

--PG