Ultra Beginner Question/Request
Frank D. Engel, Jr.
fde101 at fjrhome.net
Mon Feb 7 08:52:23 CST 2005
-----BEGIN PGP SIGNED MESSAGE-----
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:
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
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
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
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:
send addWhatever to me
Then in each of the cards, something like this (say, a list of inmates):
disable button "+"
go to card "add an inmate"
Now in the "add an inmate" card, once the inmate has been added or the
on mouseUp -- in a "Save"/"OK" or "Cancel" button
-- perform needed database actions, if any
enable button "+"
go to card "inmate list"
> 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
> use-revolution mailing list
> use-revolution at lists.runrev.com
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
-----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
More information about the use-livecode