It would be great if v5 included a string property for a session that could
be set at runtime and was visible in the administrator utility.

That way, even though one might use a single user login for all computers at
a site, a field could identify who or what computer was actually logged in.

I see myself setting it at runtime to:
Session.Comment := WindowsUser+WindowsStation+UserIDLoggedIntoMyProgram

-Johnnie

Johnnie,

<< It would be great if v5 included a string property for a session that
could be set at runtime and was visible in the administrator utility.

That way, even though one might use a single user login for all computers
at a site, a field could identify who or what computer was actually logged
in. >>

How about if we simply add the Windows user and computer name information to
the session information ?  We already track this information, but we simply
don't display it.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:8A0B8739-D7CA-43BC-BF01-BBD2435D2EA2@news.elevatesoft.com...
> Johnnie,
>
> << It would be great if v5 included a string property for a session that
> could be set at runtime and was visible in the administrator utility.
>
> That way, even though one might use a single user login for all computers
> at a site, a field could identify who or what computer was actually logged
> in. >>
>
> How about if we simply add the Windows user and computer name information
> to the session information ?  We already track this information, but we
> simply don't display it.

That would be helpful for sure.

But being able to set something programmatically would be even better. My
program requires a login from a list of users because many offices have
public computers running all day with a default user login.

-Johnnie

Hi Tim,

> How about if we simply add the Windows user and computer name information
> to the session information ?  We already track this information, but we
> simply don't display it.

Yup, that would be excellent! I would also like to see Jonnie's suggestion
too.

--
Best regards

Steve

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:8A0B8739-D7CA-43BC-BF01-BBD2435D2EA2@news.elevatesoft.com...
> Johnnie,
>
> << It would be great if v5 included a string property for a session that
> could be set at runtime and was visible in the administrator utility.
>
> That way, even though one might use a single user login for all computers
> at a site, a field could identify who or what computer was actually logged
> in. >>
>
> How about if we simply add the Windows user and computer name information
> to the session information ?  We already track this information, but we
> simply don't display it.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Tim,

That is an excellent idea! I am running into more situations where
clients are asking for this information.

--
Regards,
Jan Ferguson


Tim Young [Elevate Software] wrote:

> Johnnie,
>
> << It would be great if v5 included a string property for a session
> that could be set at runtime and was visible in the administrator
> utility.
>
> That way, even though one might use a single user login for all
> computers at a site, a field could identify who or what computer was
> actually logged in. >>
>
> How about if we simply add the Windows user and computer name
> information to the session information ?  We already track this
> information, but we simply don't display it.

Tim

Tim Young [Elevate Software] wrote:
....
> How about if we simply add the Windows user and computer name
> information to the session information ?  We already track this
> information, but we simply don't display it.

Btw, if you are working on srvadmin: please add a button to kill all clients
that are disconnected. After an hour of debugging, quite some Ctrl-F2 etc,
there are 20 or more connections dangling around, making it hard to execute
a SQL command that needs exclusive access. Oh, and another button to throw
out everybody

Ralf

Johnnie,

<< But being able to set something programmatically would be even better. My
program requires a login from a list of users because many offices have
public computers running all day with a default user login. >>

Okay, it's not a problem to do both.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:F15B8945-C518-4F1F-AC05-1E82D3B0A5C1@news.elevatesoft.com...
> Johnnie,
>
> << But being able to set something programmatically would be even better.
> My program requires a login from a list of users because many offices have
> public computers running all day with a default user login. >>
>
> Okay, it's not a problem to do both.

Wonderful!

Yippee!!!

--
Regards,
Jan Ferguson


Tim Young [Elevate Software] wrote:

> Johnnie,
>
> << But being able to set something programmatically would be even
> better. My program requires a login from a list of users because many
> offices have public computers running all day with a default user
> login. >>
>
> Okay, it's not a problem to do both.

Tim

"J. B. Ferguson" <jbNOSPAMfergusonATgmailDOTcom> wrote in message
news:98EB810D-036E-4E69-A93B-AEA122EA9799@news.elevatesoft.com...
> Yippee!!!

I cannot stress to other developers how great the support (and far beyond)
is from Elevate. I do so at every chance I get.

-Johnnie