RE: [U2] messaging to client PC / accessibility
It's tough to discuss solutions without getting slammed for solicitation. My passion and business happen to be the creation of unique solutions. That's what I'll talk about here but I will offer to take continued discussion off-list. If someone is offended by such things then feel free to stop reading now. > From: Tony G > You guys are describing a new product I've been developing as > time permits: > removepleaseNebula-RnD.com/blog/tech/mv/2008/09/remotecontrol1.ht ml > From: Dave Reynolds > Tony, Does it need testing for accessibility? The utility was created to address common questions like: - How do I do something on the client PC when the GUI is a browser? - How do I do X on the client when I'm not sure which terminal emulator the user has? - How can I get messages to people without them being logged in? - How do I put data on the client PC or get data from the client PC with MV BASIC? - Or simply, How do I do one of those popup notifications from the server like any client-side app does? Frankly, most people don't recognize a need for this sort of functionality until they themselves have it and find that there is (was) no easy solution, so there isn't a lot of demand yet even for a "non-accessible" version. Accessibility for the visual or physically impaired can only come after the product has achieved general acceptance, and this offering isn't there yet. However, if you have some demand to justify the effort, sure we can get the notifications to do audio too as a start. Just for reference, however, we do have utilities that make and receive calls via Skype (and PBX), and use IM to exchange data with the MV app. I was using this to text inquiries to my system like "where is the nearest Starbucks", and to call me when a backup finished. These are ideally suited as alternative UI's for accessibility compliance, but haven't been productized yet for lack of demand. Efforts like this are "chicken and egg" - some people wish the features were available but don't say anything until after the features exist, but "build it and they will come" is tough too. To avoid inconveniencing our colleagues here, please feel free to continue this discussion on the Nebula R&D forum. remove.pleaseNebula-RnD.com/forum Thanks for asking! Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] UniData and EasyLable
Is anybody running EasyLabel with a UniData ODBC connection? I'm running UniData 6.0.8 on AIX 4.3.3 unix system. I'm trying to get EasyLabel 5.8.0.1282, on a winXP-PRO sp3, to use ODBC and connect with UniData. I have already created the UCI, and setup up definitions with VSG. I have other tools VB and web sites that have no problem connecting to UniData with ODBC. Thanks. - -- Arthur Metherall Courier Corporation -- -- View this message in context: http://www.nabble.com/UniData-and-EasyLable-tp20860809p20860809.html Sent from the U2 - Users mailing list archive at Nabble.com. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] DEBUG mode on a UniObjects connections
Brian:
Of course, it'd be nice if the dbms would log happenings within its own
environment, like a UniData BASIC runtime log. It's a pain for regular
folk to have to build such basic functionality within the dbms (or step
through such hoops to get this basic information). :-)
Bill
Brian Leach wrote on 12/5/2008 12:55 AM:
These are all good approaches, but the difficulty is often in trying
to collate the information on what is happening client side and server
side: that usually means poring through multiple log files, especially
if you use different client languages as we did in my last company.
Our approach was to build a global logging client that would display
logging messages from client and server in the same window (colour
coded to make it easier). That way we could watch what was going on in
real time when simulating events, rather than having to wait to close
down the programs successfully and then go through the logs afterwards.
The client components used COM to broadcast to the logger and the
server components used sockets. In that way they would just check to
see if the logger was running when they started up and begin to log if
it was, or bypass the logging if not (there's some magic number
handling as well to ensure it is a legitimate client!). No switches to
turn on and forget to turn off again.
I'll try to get an article on it for the next edition of Spectrum,
deadlines permitting.
Brian
- Original Message - From: "Hona, David S" <[EMAIL PROTECTED]>
To:
Sent: Friday, December 05, 2008 5:02 AM
Subject: RE: [U2] DEBUG mode on a UniObjects connections
Note that the SYSTEM(9001) function call returns the runtime stack.
I use a generic logging subroutine that writes to a sequential file any
information I want to log:
call @debuglogger("Starting phase 1")
In debuglogger, it writes out timedate stamp, PID, @USERNO, @WHO, @PATH,
etc., etc. along with the desired message. We have a global common flag
to toggle it on/off or output to screen, as well.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave Reynolds
Sent: Friday, 5 December 2008 1:23 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] DEBUG mode on a UniObjects connections
Interesting idea that.
As standard, all subroutine calls in our software add to a "Stack" and
their names are deleted from the stack when control is returned to the
calling level. It doesn't solve the debug issue, but has given me an
idea about tracing. I'm sure the code was originally designed for such a
purpose, it was just never implemented.
Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Israel, John R.
Sent: 04 December 2008 13:31
To: 'u2-users@listserver.u2ug.org'
Subject: RE: [U2] DEBUG mode on a UniObjects connections
Just chiming in on the debugging in a web page which might also help
here since you loose the ability to interact.
I have written a universal E-mailing program that can be called from any
UniData program. It will work with both simple text or HTML depending
on how much effort the programmer wants to exert.
There are several simple INCLUDES that store COMMON info so that I can
just plug this into any subroutine I want.
Starting with my top-most subroutine (the one called by Redback), I
INCLUDE my setup code and set a COMMON flag as either null (disable
debugging E-mail) or with the name of the ASP web page (enabling the
debugging E-mail).
At critical points, I test if the E-mailing flag is turned on, and if
so, create an E-mail with all the critical info I might want at that
point, then send the E-mail to myself. This E-mail includes the
initiating web page and all subroutines that have been called to get to
the current subroutine.
---
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/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] DEBUG mode on a UniObjects connections
Tony, Does it need testing for accessibility? Thanks, Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony G Sent: 05 December 2008 12:16 To: u2-users@listserver.u2ug.org Subject: RE: [U2] DEBUG mode on a UniObjects connections You guys are describing a new product I've been developing as time permits: removepleaseNebula-RnD.com/blog/tech/mv/2008/09/remotecontrol1.ht ml Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com > From: Dave Reynolds > Brian, > This sounds like a good approach to me. I've recently > written a phantom launcher which as part of the gui > client, and whilst the phantoms it launches generate > their own logs, it would be nice to have a gui program > which told me what was going on. Sometimes a phantom > hangs, and you haven't got a clue why. I'll probably > skip the colour bit for obvious reasons, but just have > two separate windows open, one populated with the > client log, and the other populated with the server > side log. > From: Brian Leach > These are all good approaches, but the difficulty is > often in trying to collate the information on what is > happening client side and server side... > > Our approach was to build a global logging client that > would display logging messages from client and server > ... The client components used COM to broadcast to the > logger and the server components used sockets. --- 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/
RE: [U2] DEBUG mode on a UniObjects connections
You guys are describing a new product I've been developing as time permits: removepleaseNebula-RnD.com/blog/tech/mv/2008/09/remotecontrol1.ht ml Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com > From: Dave Reynolds > Brian, > This sounds like a good approach to me. I've recently > written a phantom launcher which as part of the gui > client, and whilst the phantoms it launches generate > their own logs, it would be nice to have a gui program > which told me what was going on. Sometimes a phantom > hangs, and you haven't got a clue why. I'll probably > skip the colour bit for obvious reasons, but just have > two separate windows open, one populated with the > client log, and the other populated with the server > side log. > From: Brian Leach > These are all good approaches, but the difficulty is > often in trying to collate the information on what is > happening client side and server side... > > Our approach was to build a global logging client that > would display logging messages from client and server > ... The client components used COM to broadcast to the > logger and the server components used sockets. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] DEBUG mode on a UniObjects connections
Spectrum is available from www.intl-spectrum.com.
Several list members write for the publication, and the editor is the previous
host of this list.
You can download back-issues in pdf format.
Brian
Brian,
This sounds like a good approach to me. I've recently written a phantom
launcher which as part of the gui client, and whilst the phantoms it
launches generate their own logs, it would be nice to have a gui program
which told me what was going on. Sometimes a phantom hangs, and you
haven't got a clue why. I'll probably skip the colour bit for obvious
reasons, but just have two separate windows open, one populated with the
client log, and the other populated with the server side log.
How do I get hold of Spectrum?
Thanks,
Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brian Leach
Sent: 05 December 2008 08:55
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] DEBUG mode on a UniObjects connections
These are all good approaches, but the difficulty is often in trying to
collate the information on what is happening client side and server
side:
that usually means poring through multiple log files, especially if you
use
different client languages as we did in my last company.
Our approach was to build a global logging client that would display
logging
messages from client and server in the same window (colour coded to make
it
easier). That way we could watch what was going on in real time when
simulating events, rather than having to wait to close down the programs
successfully and then go through the logs afterwards.
The client components used COM to broadcast to the logger and the server
components used sockets. In that way they would just check to see if the
logger was running when they started up and begin to log if it was, or
bypass the logging if not (there's some magic number handling as well to
ensure it is a legitimate client!). No switches to turn on and forget to
turn off again.
I'll try to get an article on it for the next edition of Spectrum,
deadlines
permitting.
Brian
- Original Message -
From: "Hona, David S" <[EMAIL PROTECTED]>
To:
Sent: Friday, December 05, 2008 5:02 AM
Subject: RE: [U2] DEBUG mode on a UniObjects connections
> Note that the SYSTEM(9001) function call returns the runtime stack.
>
> I use a generic logging subroutine that writes to a sequential file
any
> information I want to log:
>
> call @debuglogger("Starting phase 1")
>
> In debuglogger, it writes out timedate stamp, PID, @USERNO, @WHO,
@PATH,
> etc., etc. along with the desired message. We have a global common
flag
> to toggle it on/off or output to screen, as well.
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dave Reynolds
> Sent: Friday, 5 December 2008 1:23 AM
> To: u2-users@listserver.u2ug.org
> Subject: RE: [U2] DEBUG mode on a UniObjects connections
>
> Interesting idea that.
> As standard, all subroutine calls in our software add to a "Stack" and
> their names are deleted from the stack when control is returned to the
> calling level. It doesn't solve the debug issue, but has given me an
> idea about tracing. I'm sure the code was originally designed for such
a
> purpose, it was just never implemented.
>
>
>
> Dave
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Israel, John
R.
> Sent: 04 December 2008 13:31
> To: 'u2-users@listserver.u2ug.org'
> Subject: RE: [U2] DEBUG mode on a UniObjects connections
>
> Just chiming in on the debugging in a web page which might also help
> here since you loose the ability to interact.
>
> I have written a universal E-mailing program that can be called from
any
> UniData program. It will work with both simple text or HTML depending
> on how much effort the programmer wants to exert.
>
> There are several simple INCLUDES that store COMMON info so that I can
> just plug this into any subroutine I want.
>
> Starting with my top-most subroutine (the one called by Redback), I
> INCLUDE my setup code and set a COMMON flag as either null (disable
> debugging E-mail) or with the name of the ASP web page (enabling the
> debugging E-mail).
>
> At critical points, I test if the E-mailing flag is turned on, and if
> so, create an E-mail with all the critical info I might want at that
> point, then send the E-mail to myself. This E-mail includes the
> initiating web page and all subroutines that have been called to get
to
> the current subroutine.
> ---
> 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/
---
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
RE: [U2] DEBUG mode on a UniObjects connections
Brian,
This sounds like a good approach to me. I've recently written a phantom
launcher which as part of the gui client, and whilst the phantoms it
launches generate their own logs, it would be nice to have a gui program
which told me what was going on. Sometimes a phantom hangs, and you
haven't got a clue why. I'll probably skip the colour bit for obvious
reasons, but just have two separate windows open, one populated with the
client log, and the other populated with the server side log.
How do I get hold of Spectrum?
Thanks,
Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brian Leach
Sent: 05 December 2008 08:55
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] DEBUG mode on a UniObjects connections
These are all good approaches, but the difficulty is often in trying to
collate the information on what is happening client side and server
side:
that usually means poring through multiple log files, especially if you
use
different client languages as we did in my last company.
Our approach was to build a global logging client that would display
logging
messages from client and server in the same window (colour coded to make
it
easier). That way we could watch what was going on in real time when
simulating events, rather than having to wait to close down the programs
successfully and then go through the logs afterwards.
The client components used COM to broadcast to the logger and the server
components used sockets. In that way they would just check to see if the
logger was running when they started up and begin to log if it was, or
bypass the logging if not (there's some magic number handling as well to
ensure it is a legitimate client!). No switches to turn on and forget to
turn off again.
I'll try to get an article on it for the next edition of Spectrum,
deadlines
permitting.
Brian
- Original Message -
From: "Hona, David S" <[EMAIL PROTECTED]>
To:
Sent: Friday, December 05, 2008 5:02 AM
Subject: RE: [U2] DEBUG mode on a UniObjects connections
> Note that the SYSTEM(9001) function call returns the runtime stack.
>
> I use a generic logging subroutine that writes to a sequential file
any
> information I want to log:
>
> call @debuglogger("Starting phase 1")
>
> In debuglogger, it writes out timedate stamp, PID, @USERNO, @WHO,
@PATH,
> etc., etc. along with the desired message. We have a global common
flag
> to toggle it on/off or output to screen, as well.
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dave Reynolds
> Sent: Friday, 5 December 2008 1:23 AM
> To: u2-users@listserver.u2ug.org
> Subject: RE: [U2] DEBUG mode on a UniObjects connections
>
> Interesting idea that.
> As standard, all subroutine calls in our software add to a "Stack" and
> their names are deleted from the stack when control is returned to the
> calling level. It doesn't solve the debug issue, but has given me an
> idea about tracing. I'm sure the code was originally designed for such
a
> purpose, it was just never implemented.
>
>
>
> Dave
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Israel, John
R.
> Sent: 04 December 2008 13:31
> To: 'u2-users@listserver.u2ug.org'
> Subject: RE: [U2] DEBUG mode on a UniObjects connections
>
> Just chiming in on the debugging in a web page which might also help
> here since you loose the ability to interact.
>
> I have written a universal E-mailing program that can be called from
any
> UniData program. It will work with both simple text or HTML depending
> on how much effort the programmer wants to exert.
>
> There are several simple INCLUDES that store COMMON info so that I can
> just plug this into any subroutine I want.
>
> Starting with my top-most subroutine (the one called by Redback), I
> INCLUDE my setup code and set a COMMON flag as either null (disable
> debugging E-mail) or with the name of the ASP web page (enabling the
> debugging E-mail).
>
> At critical points, I test if the E-mailing flag is turned on, and if
> so, create an E-mail with all the critical info I might want at that
> point, then send the E-mail to myself. This E-mail includes the
> initiating web page and all subroutines that have been called to get
to
> the current subroutine.
> ---
> 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/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] DEBUG mode on a UniObjects connections
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/
Re: [U2] DEBUG mode on a UniObjects connections
These are all good approaches, but the difficulty is often in trying to
collate the information on what is happening client side and server side:
that usually means poring through multiple log files, especially if you use
different client languages as we did in my last company.
Our approach was to build a global logging client that would display logging
messages from client and server in the same window (colour coded to make it
easier). That way we could watch what was going on in real time when
simulating events, rather than having to wait to close down the programs
successfully and then go through the logs afterwards.
The client components used COM to broadcast to the logger and the server
components used sockets. In that way they would just check to see if the
logger was running when they started up and begin to log if it was, or
bypass the logging if not (there's some magic number handling as well to
ensure it is a legitimate client!). No switches to turn on and forget to
turn off again.
I'll try to get an article on it for the next edition of Spectrum, deadlines
permitting.
Brian
- Original Message -
From: "Hona, David S" <[EMAIL PROTECTED]>
To:
Sent: Friday, December 05, 2008 5:02 AM
Subject: RE: [U2] DEBUG mode on a UniObjects connections
Note that the SYSTEM(9001) function call returns the runtime stack.
I use a generic logging subroutine that writes to a sequential file any
information I want to log:
call @debuglogger("Starting phase 1")
In debuglogger, it writes out timedate stamp, PID, @USERNO, @WHO, @PATH,
etc., etc. along with the desired message. We have a global common flag
to toggle it on/off or output to screen, as well.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave Reynolds
Sent: Friday, 5 December 2008 1:23 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] DEBUG mode on a UniObjects connections
Interesting idea that.
As standard, all subroutine calls in our software add to a "Stack" and
their names are deleted from the stack when control is returned to the
calling level. It doesn't solve the debug issue, but has given me an
idea about tracing. I'm sure the code was originally designed for such a
purpose, it was just never implemented.
Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Israel, John R.
Sent: 04 December 2008 13:31
To: 'u2-users@listserver.u2ug.org'
Subject: RE: [U2] DEBUG mode on a UniObjects connections
Just chiming in on the debugging in a web page which might also help
here since you loose the ability to interact.
I have written a universal E-mailing program that can be called from any
UniData program. It will work with both simple text or HTML depending
on how much effort the programmer wants to exert.
There are several simple INCLUDES that store COMMON info so that I can
just plug this into any subroutine I want.
Starting with my top-most subroutine (the one called by Redback), I
INCLUDE my setup code and set a COMMON flag as either null (disable
debugging E-mail) or with the name of the ASP web page (enabling the
debugging E-mail).
At critical points, I test if the E-mailing flag is turned on, and if
so, create an E-mail with all the critical info I might want at that
point, then send the E-mail to myself. This E-mail includes the
initiating web page and all subroutines that have been called to get to
the current subroutine.
---
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/
