Ultra Beginner Question/Request

[Len Morgan]

I'd like to thank everyone that offered help about this!  It appears that my original question (or more accurately the answers I was looking for) were misinterpreted.  I know how to program, I'm familiar with event driven programming (the Tk GUI is also event driven), and with what is going through a user's head when they are staring at the screen).  I also am familiar with client/server applications (that's what mine is) with a database backend (I currently use Postgres and when a customer requires it - MS SQL).

Frank got the closest to answering my question. Thanks Frank!!  I think the word I should have used instead of "design" is partition.  What cards/stacks would I divide up the functions on to.  If I understand Frank's response (recommended reading for ANYONE just starting out!) I'd have a main stack to get everything up and running, then a stack just for the database operations, and cards on the main stack for each of the "pages" that do something.
 
I agree with prior comments that you should probably bite off a smaller 
chunk of the program first (do simpler related projects in order to 
become familiar with Rev before trying to tackle a larger project like 
this), but in the meantime here are some pointers to help direct you in 
what you will want to research during that time:

> I recommend PostgreSQL if you are not already using a compatible 
> database server 

Already using Postgres (see above). 


>The menu should be created almost first in your project, as it can 
>throw off your interface if you try to add it later.  Even if you do 
>not include every menu and item right away, if you are going to have a 
>menu in any particular stack, create one right away, even if it is just 
>a placeholder at first.  You can use the Menu Builder (in the Tools 
>menu).

The menu was actually the easiest part but I'm curious why it would throw off the process if it was saved until later?  Is it because it adds to the window size and therefore throws off all of the carefully laid out GUI?

> Rev does not have native support for Toolbars, but you can rather 
> easily "fake" one just by placing controls appropriately and managing 
> window resizes as needed.

My Tcl/Tk extensions don't have a toolbar either and I managed to "fake" it there too so I don't see this as a big problem.

> Interface layout becomes *much* simpler if 
> you can use a fixed-size stack window; if you want it to be resizable, 
> spend some time with some prototype interfaces learning to use the 
> Geometry Manager (the Geometry pane of the Properties palette for 
> various kinds of objects) as there are some hidden gotchas that are not 
>always obvious when you just get started.

I am fortunate here because my app only runs in two sizes: maximized and minimized.  :-)

>> select what the user wants to do, a "current inmate" frame which is 
>> only a little taller than the text and labels that are on it, a large
>> "main area" where different things go depending on what you select 
>> from the combobox, and at the bottom a status/progess bar. In a
>  
>

> As for the two frames, 
> you really have two different options, and what is best will depend on 
> the specific program and the approach you are more comfortable with.

> As for the "current inmate" frame: is there exactly one version of this 
> frame, or are there multiple possible interfaces that could be placed 
> here?  If just one, I would suggest this approach:

The "current inmate" frame ALWAYS shows the inmate the user is currently working with (and thus, the name).  Making it a group and having it act like a background sounds like exactly what I need since it WILL be displayed on every card, even when those pages that don't directly relate to an inmate are displayed although with RR, it might not be necessary to put it on these "extra" pages.

> Warning:  Note that buttons have a "shared highlight" property, and 
> fields have a "shared text" property.  If the "shared text" property of 
> a field is turned ON, then the content of the field will be the same 
> regardless of what card you look at.

This is EXACTLY the behavior I'm looking for.  The "current inmate" frame holds general information (ID#, name, DOB, Quarters, Day In, etc) and the individual cards contain more specific information (one might have family details and physical description, another his commissary account history, another his movement history, etc).

> The other approach is to use a single card for the entire interface.  
> Now you group the controls for each of the interfaces in the other 
> pane, hide all of the groups except the one you want to be visible, and 
> show the one that should be visible.  This allows multiple panes to 
> have multiple interfaces, and allows them to be changed independently 
>of each other.

This sounds like it could be a little "messy."  For me, I think the first approach is the way to go.

> Another warning: a group marked to act as a background is inserted just 
> before the card in the message path.  In other words, if a handler for 
> a message sent to a control is not found in the script of that control, 
> then even if that control is not in the group, if the group's script 
> contains a handler for that message, it will intercept the message 
> before the card receives it.  I recommend not assigning a script to a 
> group if you can avoid it, at least until you realize the implications 
> of this (and have some experience with Rev and its message path), 
>particularly when dealing with background groups.

Warning taken (if not fully understood).  Is there a "message trace" utility that might show the path of a message through various controls, groups, cards, and stacks?  It seems like this kind of a tool would find problems like this quickly.

> If you go with the multiple cards-shared group approach, these buttons 
> could be in a shared group and each have a script which sends a custom 
> message to itself.  Let the message pass through to the card script, 
> where it would be handled for the specific interface you are looking 
> at.  So for example, in the "+" button script:

> on mouseUp
>   send addWhatever to me
> end mouseUp


> Then in each of the cards, something like this (say, a list of inmates):

> on addWhatever
>    disable button "+"
>    go to card "add an inmate"
> end addWhatever

> Now in the "add an inmate" card, once the inmate has been added or the 
> action cancelled:

> on mouseUp  -- in a "Save"/"OK" or "Cancel" button
>   -- perform needed database actions, if any
>   enable button "+"
>   go to card "inmate list"
> end mouseUp

This makes sense and is effectively the way I'm doing it in Tcl/Tk.  What I do in my current system is to change the handler for the button when I display different pages (cards) and each of the pages has an add handler, save handler, etc.

> I like to handle these things by disabling buttons and fields as 
> appropriate from within the login handler.  So after authenticating 
> with the database and figuring out what the current user can do, I 
> disable any buttons and fields that I know ahead of time will apply 
> everywhere, then I use custom properties of the stack to track what a 
> user may do.  Then for things which need to be adjusted dynamically, I 
> handle enable/disable in a preOpenCard handler, or on-the-fly as 
> various events take place which could change that, by using those 
> custom properties to determine who may do what.


This is probably the only point where I might disagree with you (at least if I understand what you are saying).  There is another program by another company that does the same job that mine does and they use this approach except they have a vertical scrolling list of buttons down the right hand side of the screen.  283 of them and they all APPEAR active (i.e., not grayed out). 283!!!  If they press a button that they don't have access to, they get an error message. Most users need at most 5 or 6 of them but they have to scroll up and down the list to find those 5 or 6 (which seem to be arranged in the order that they thought of them, not alphabetical, not grouped by function).  When my program has been compared side to side with this one, I always "win" when it comes to user friendlyness because all a user ever sees is what they need for their particular job function.  See more comments below after the next section... 


 > Yep, use the groups like that and enable/disable as I mentioned above.
 > Use the same cards for each profile, then just enable or disable

> buttons and fields depending on the access level of the user.  You can 
> also show or hide fields and buttons if that is more useful, but I 
> would advise you to keep that to a minimum if your objective is 
> security control.  Much better to disable controls than to hide them.  
> Use the database to handle your search (with SQL SELECT statements).

I think what I'd really like to do, taking into account the suggestion above and in other messages, is to have a main stack to get things going and a database interface stack to handle that end.  The main stack would get login information and find out which "profile" we are going to use.

The profiles would be individual stacks that held one profile each with cards for each page that profile needs.  Is it possible to "load" cards into a stack at run time?  In other words, could I create one "search" card on a stack of utility pages, and say a card for room changes and another for facility changes on a "movement cards" stack and then load these separate cards "onto" the "records clerk" stack (say from a list of stacks/cards stored on the records clerk stack?  If I could do that, then if I made a change to the search card, the next time a record clerk logged in, they would get the latest version of this card.  The other alternative is to put the actual cards necessary on each profile stack and then if I made a change to the search card, I would have to copy it to all of the other profile stacks (since they ALL have the search card).  That could work but the first way seems a lot more practical.

It would be great if you could embed stack within another (like in a smaller window) but I don't think RR can do that.  It would be a cool feature though with lots of possibilities.

> I still recommend an SQL engine for this kind of project, however, as it 
> gives you multiuser support almost "for free" and it will be *much* 
> faster at searching, and make it easier to enforce tighter security.

As I said above, I'm already using a backend SQL database.  One of my customers has over 22,000 inmates in file (current and past) and well over 1/2 a million commissary transactions.  I have no idea how many commissary line items there are (I store every line item when an inmate makes a purchase in the commissary so I could tell you if an inmate bought a Snickers bar 3 years ago on a Wednesday in May (and do it in under a second). Go Postgres!!!


Again, thanks for ALL the input from everyone.  I hope others are benefiting from this exchange than just me!

Len Morgan