Ultra Beginner Question/Request

[Frank D. Engel, Jr.]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Feb 7, 2005, at 10:35 PM, Len Morgan wrote:
>> I recommend PostgreSQL if you are not already using a compatible 
>> database server
>
> Already using Postgres (see above).

Cool.

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

Just the opposite.  The menu bar would overlap the top portion of the 
card, sitting on top of whatever controls you had placed there and 
obscuring them, rendering them inaccessible.  On a Mac, when the menu 
bar is used correctly, the window will be reduced in size (as the menu 
bar is at the top of the screen, separate from any windows), and the 
window is reduced in size, chopping of the part of the window which 
would be obscured by the menu bar on other platforms.

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

Again, that will make life easier.

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

Not that I am aware of, but this is not a bad idea, necessarily.  For 
info about the message path, go to the "Topics" area of the Rev 
documentation, and look at the "Messages and the message path" item in 
the list.  You can always run questions by the list if you have them.

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

A scrolling list of buttons is a bad idea to begin with.  Failure to 
disable them (using an error message instead) is rather lazy.  My 
suggestion to disable the buttons implies causing them to appear 
disabled (graying the text, etc).

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

Some interface elements can be appropriately hidden in this manner, 
depending on what they are and how the interface is set up.  However, 
some things should never be hidden in this way, but merely disabled.  
For example, say there is a menu of different program areas in your 
menu bar.  If some are inaccessible, you should always disable the 
items, not hide them.  (Obviously, a Window menu lists open windows, so 
only open windows should be included) - it depends on the semantics of 
the control and its placement in the interface.  You should definitely 
be careful about this, though.

> 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

Not easily; it would be better to include all of the cards in your 
stack, and when switching cards just switch to the version you want to 
display.  So if there are three versions of some particular card, name 
them (ex.) "Inmates 1", "Inmates 2", "Inmates 3", and when switching to 
an Inmates card, choose one based on your security/profile criteria.

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

You can do this; these are called "substacks".  Each appears in a 
separate window, as a standard window, a dialog box (or a sheet under 
OS X, if desired), or even as a floating palette window (which has a 
rather distinct appearance on Macs, and which hides itself 
automatically when the user switches to a different application).

You can also have multiple main stacks loaded and they can interact 
with each other.  You can load additional mainstacks from a standalone 
after it has opened, as well.

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

iD8DBQFCCOfx7aqtWrR9cZoRAoMUAJ9t0/rLYnDvreimCi2yVEpP8JDFigCgj5bH
OwnUe0PvWDZVN1o1SpQS0W8=
=KvtL
-----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