Tony, I think you are right. Since all our routines take three parameters, InPar, OutPar, and ErrStat, we have a routine which can be run as part of a telnet session, thus decreasing the likelihood of a routine crashing when called from VB. Ordinarily, what I'd do is run this program, and call the routine, passing it relevant information. In most cases, any crashes due to typos or logical errors can be eliminated at this stage, but there is always the odd one that doesn't.
Thanks for help, Dave -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony G Sent: 05 December 2008 02:51 To: u2-users@listserver.u2ug.org Subject: RE: [U2] DEBUG mode on a UniObjects connections Dave, if you suspect a server-side routine might fall to debug then I'd recommend putting server access into a separate client-side thread. That doesn't stop the aborts, but it does prevent such things from affecting the end-user's session. Having a lot of experience with the visually-impaired (and speech synthesis and voice recognition development), I think is very important in this case. If you detect an abort you can use a separate channel (email, web service, etc) to get a message back to you or the server admin. HTH Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com Nebula R&D sells mv.NET and other Pick/MultiValue products worldwide, and provides related development and training services Dave wrote: > The client screen locks up, and my talking > screenreader goes into sulk mode, which normally means > I have to reboot. > > I wouldn't expect anyone on the list to solve the > screenreader problem, but sighted colleagues have > reported similar experiences with this type of > connection. ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
