forum home | register | profile | members |search | faq
homepage | lost password? | chat room
|
|
QSA ToolWorks Public Feedback Forum forum home | register | profile | members |search | faq homepage | lost password? | chat room |
| QSA ToolWorks Public Feedback Forum > Changes to Specification > The Way Users are Managed in Client/Server | You are not logged in. Login or Register. |
| Pages: 1 |
|
| Author: | Topic: The Way Users are Managed in Client/Server | |||
Matt Posts: 107 Registered: 2003-02-16  mstrange@mac.com  |
 Posted: Jun 15, 2004 4:56:42 pm    
In working on the code, we have unraveled a rather interesting behavior related to users when running under Helix Client/Server. We want to try to do two things... First: document the behavior and 2nd: make the behavior consistent. The latter requires one change, which we are requesting feedback on here... Related to a Helix Client that is disconnecting from a Server, there are four possible conditions...
Currently (and as far back as structure files existed) Case 1 (Visit/Don't Save) results in the actual user icon's underlying object being altered in the collection, in an attempt to retain the user's open windows and window positions. In the other 3 cases no change is made to the actual user icon's object. It makes sense that if the user is saving structure locally (or is working from a previously saved structure) that the user icon on the Server does not need to be updated, so that leaves Case 1 as the odd man out. In the interest of code simplification and user interaction consistency, we would like to simply remove Case 1's ability to change the user icon as stored in the collection itself. This would have a negative impact only for people who are used to having the Server 'remember' their window positions without the added benefits that the saved structure file provides. It is important to note that the "Visit/Don't Save" mechanism ONLY stores a window's open/closed and position settings. It does not include query settings, view sort orders, or even the current record that is open on the form. (All of these are preserved in a structure file.) Another interesting twist to this spec: if you have a user name that is shared by more than one person, and multiple people can log on using it at the same time, each person who logs on is presented with whichever windows were left open by the last person to leave. In other words, you can never predict what will be presented to a user who signs in this way. In summary, given the limitations of the current mechanism, the inconsistency of the specification, the available alternatives, and our desire to simplify the code, are there any objections to making this change? - Edited by Matt on: Jun 16, 2004 9:07:03 pm
|
|||
dkuchta Posts: 40 Registered: 2003-04-09 |
Posted: Jun 16, 2004 7:10:10 am
No objections here. -Dan Kuchta
|
|||
lucidlee Posts: 18 Registered: 2003-04-09 |
Posted: Jun 16, 2004 1:06:35 pm
I agree.
|
|||
Michael S. Scaramella, Esq. Posts: 7 Registered: 2003-04-09 |
 Posted: Jun 16, 2004 5:33:59 pm
I think the proposed change would be an improvement.
|
|||
| Matt Posts: 107 Registered: 2003-02-16 mstrange@mac.com |
Posted: Jun 16, 2004 9:15:56 pm
I should add one extra note: one programmer suggested that we retain the current behavior (saving window positions in the collection) if (and only if) the user icon is set to allow just one log in under that name. Or to say it the other way: a user set to 'infinite' or a number greater than one would stop updating the collection structure. To those who already commented: If this new info doesn't change your opinion, no need to re-comment. (oh, and "thank you" for commenting!)
|
|||
gibhenry Posts: 5 Registered: 2003-04-26 GibH gibhenry@hotmail.com |
Posted: Jun 17, 2004 12:49:37 am
I concur...and I have multiple users using the same template. -- Gib Henry
|
|||
| Paul Hathcoat Posts: 8 Registered: 2003-04-09 |
Posted: Jun 17, 2004 7:55:01 am
I'm not used to "me to-ing' but I agree to would be an improvement. I will say I'm impressed that the original programming went to that effort to try to give the user a consistant experence. And on the other side of the coin, I'l say that I always *really* disliked the structure file being deleted if the user didn't choose to save, and then replace it.
|
|||
Sven Posts: 24 Registered: 2003-04-09 |
Posted: Jun 17, 2004 9:05:36 am
I have nothing against the proposed change to the specification. Sven
|
|||
| chuckbo Posts: 42 Registered: 2003-04-09 |
Posted: Jun 17, 2004 1:15:46 pm
I think it's a good plan, as long as we keep behind us the problems that once were associated with saving structure. |
| Pages: 1 |
|
| Lost Password? Powered by UPB Version : 1.8 A script by PHP Outburst |
