Ultra Beginner Question/Request

Mon Feb 7 09:52:23 EST 2005

On Feb 4, 2005, at 5:24 PM, Len Morgan wrote:

> I have no doubt this is the right place to at least get started! The 
> project I'm trying to convert is large but I think it is also typical 
> of a lot of moderately complex application so I hope others can 
> benefit from this discussion. The program has a database on the 
> backend

You can do this in Rev as well, using the RevDB external (included with 
Rev and automatically available).  Numerous database engines are 
supported as back ends; assuming you have some basic familiarity with 
SQL.  I recommend PostgreSQL if you are not already using a compatible 
database server (in which case, stick with what you know for now if it 
is working for you).

> and is used to manage (private) prisons. The GUI consists of a menu at 
> the top of the screen, a toolbar that includes a combobox to

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).

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.  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.

> 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

Again, the status/progress bar is easily faked.  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:

1. Design the "current inmate" frame and place the controls and other 
objects where they should be.
2. Group all objects in the "current inmate" frame and mark the group 
to act like a background.

Now that group will automatically be added to each newly created card 
in your stack, and will be shared by those cards.  You can create a 
separate card for each of the possible interfaces in the other frame, 
and switch cards to switch between them.  Since the grouped controls 
are shared by all of those cards, they will not change from one card to 
the next.

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.  If that property is turned OFF, 
the content will depend on which card you are on, even though the field 
itself is part of a single group being shared by multiple cards.  
Similarly for shared highlight, which determines (for example) whether 
or not a checkbox is checked.

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.

Note that is *is* possible to do multiple cards for one of the panes 
and use multiple background groups for the other pane, hiding/showing 
the background group as needed.

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.

> prior version of this program, the large main area had a tabset 
> control to was used to select between the various tasks that a user 
> wanted to do. As the program grew, the tabset had to be replaced with 
> the combobox on the toolbar because it gave me an (almost) unlimited 
> number of tasks (RR equivalent to cards I think). The tab control I 
> had could not scroll if it got too big (which it did). The tool bar 
> also has 4 buttons on it that are used by all of the tasks in the work 
> area ("Add", "Delete", "Save" and "Cancel Changes"). What routines are 
> called when one of these buttons are pushed depends on which task 
> screen you're looking at when it is pressed. This sounds a little 
> confusing but once you teach a user that pressing the "+" button adds 
> one of whatever you're looking at (i.e., inmate,

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

> charge, program review)), they pick it up pretty quick. Now, for an 
> additional wrinkle, in a prison environment (or really any other 
> reasonably large organization), you need to have different rights for 
> different people. In my program's case, no one but medical staff can 
> look at an inmate's medical information, and so on. When the program 
> is first started up, I get a username and password, and after 
> authenticating them against my database, I get a "profile" that has 
> been assigned to that username (from the same database). My tcl code 
> has a script for each profile (medical clerk, mailroom, records clerk, 
> case manager, etc) that loads ("sources" in Tcl lingo) the scripts for 
> each of the tasks they are allowed to preform along with certain 
> permissions on those tasks. By that I mean, everyone is allowed to 
> look at a certain screen of inmate information but only records clerks 
> are allowed to change it. There is also a menu file

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.

> that creates the top level menu structure also based on the user's 
> profile. Again, there are a set of menus that everyone gets and then 
> there are different ones added depending on the profile selected. Ok, 
> that's how I'm doing it now in Tcl/Tk. I'm not expecting anyone to 
> build this for me but I'd like a little direction on how to attack 
> this in RR. Can I get different cards (or would I use stacks) 
> depending on the profile or would I have a stack for each profile that 
> had the cards necessary on it already? If it's the latter, how would I 
> handle something like the "Search" task that everyone has but changes 
> from time to time? Would I have to make the changes on every profile 
> stack or can I say "use the Search card from ... on this stack?" I 
> think I've figured out that my toolbar, "current inmate" and statusbar 
> will endup being "groups" that I will just include on every card so 
> that it looks like only the main work area is changing when in fact (I 
> think) the whole screen is changing. I also think I've figured out 
> that I'll need a stack to handle all of the database needs that I'll 
> pass queries to and retrieve answers from. So there you have it. I'm 
> staring at a blank mainstack and

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).

If you want to use the "built-in" card-based "database", keep that 
database in a separate stack (or stacks), NOT substacks, so that they 
can be saved as needed, even if you build a standalone.  Alternative:  
Use a single external mainstack (NOT a substack of your logic stack) to 
contain multiple substacks, each of those substacks being a "table" in 
your database.  Then you can save/load the whole thing as a unit.  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.

> don't even know where to begin the design process. How do I partition 
> things so that I'm doing things the "Revolution way." Thanks in 
> advance for any pointers you might be able to offer. Len Morgan
> From: Richard Gaskin <ambassador at fourthworld.com>
>
> You may have come to the right place.  You can consider this list a 
> working group for your personal success with learning Rev.  :)
> Tell us a bit about this Tcl project and perhaps some of the folks 
> here will chime in with suggestions on how to get started.
>
> One of the tough things with learning a proprietary language is that 
> there are fewer third-party resources avaiable for learning.
>
> But one of the upsides with Rev is that this mailing list is chock 
> full o' third parties ready and willing to offer personal assistance.
>
>
> Len Morgan wrote:
>
>>> Hello All,
>>> I've been a programmer since the mid 70's.  I've used and/or 
>>> tinkered with all of the "normal" procedural languages (C, Tcl, 
>>> BASIC) and even some "ab"normal ones like Forth.  I consider myself 
>>> a pretty good programmer and have been told I'm fairly bright in 
>>> general.  I've had Revolution for a couple of weeks now, and I just 
>>> can't seem to get my head around the "methodology" of using 
>>> Revolution.
>>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
- -----------------------------------------------------------
Frank D. Engel, Jr.  <fde101 at fjrhome.net>

$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep "John 3:16"
John 3:16 For God so loved the world, that he gave his only begotten 
Son, that whosoever believeth in him should not perish, but have 
everlasting life.
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCB4Co7aqtWrR9cZoRAny0AKCF2DwhapUbwBWRSP25ghv4bW/vqgCfcoQV
Drxx8VVDQQv7T2g/U03mqmc=
=n3Sg
-----END PGP SIGNATURE-----

___________________________________________________________
$0 Web Hosting with up to 120MB web space, 1000 MB Transfer
10 Personalized POP and Web E-mail Accounts, and much more.
Signup at www.doteasy.com