date:20050208

re Text file database, moving from Mac OsX to windows

2005-02-08 Thread drphilippegiraudet

Hello
Thanks to Robert Brenstein and Klaus Major for their answers.
The question is not an encoding problem and no more a corruption of 
data because of simultaneous writing access, because I still only 
tested it in mono user access, on windows. I just realise, with what 
Robert says that the corruption by simultaneous writing access will be 
my next problem ;- ... ;-(
the problem is that when you enter a command line such as

write appointment to file Pathway at 
(1001+dayLength*(dayNumber-1)+225+(RoomNum-1)*4001+(AppNum-1)*100-1)

It writes at the rigth place  on Mac
and at the wrong place on windows!
I believe it can't be an error on calculation of the first char: 
(1001+dayLength*(dayNumber-1)+225+(RoomNum-1)*4001+(AppNum-1)*100-1)

I prefer to suppose it is a quetion of length of the chain I write : if 
some chars like return or even tab are not counted , in a 8MB text 
file, it makes a great difference at the end of the file.

but now I have another Question: Robert Brenstein, you wrote me :
"You are not handling file access correctly and the file is getting 
corrupted because more than single person tries to write to it. Setting 
up multi-user access is not so trivial. Using text files is actually 
the least optimal. It is better to work along the client-server 
approach. This means that there is a central computer designated as a 
master of data and each client computer just talks to it and displays 
data locally. Alternatively, each computer can maintain its own copy of 
the text and sporadically synchronizes with others. But the algorithm 
for synchronization can be a real headache."

So if the text file is not the rigth way for handling multi users 
database, and that my next problem will be corruption by simultaneous 
writing access, may be it is more interesting to ask you what is the 
best way to manage databases under Revolution: What is a  client-server 
approach  ? Would SQL be usefull in that case? Heard speaking about 
substacks that can save data ( and didn't understand why the mainstack 
cannot). is it possible to easily manage Multi Users access to an 
external stack? Where can I learn about those, client  server, SQL, 
External stacks? Is it realistic to try it, if I tell you that I am 
already VERY busy...!?

 Many thanks for your help
Philippe Giraudet
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Open Directory reminder

2005-02-08 Thread Dom

Richard Gaskin <[EMAIL PROTECTED]> wrote:

> You can add them to the main Transcript listing with the word "FRENCH"
> as the first word in all caps to help other French speakers find it easily.

My concern was that there is no "Transcript" entry in the french
speaking section...

As for your suggestion, at Open Directory they clearly warn against this
-- they don't want non english speaking section under the main
listing...

So, I thought simply to translate the english description under
"Transcript" title, to put it under a new "transcript" title in the
french speaking section -- but you have to be an editor to do that.

By the way, I know there is a number of french speaking people onto this
list (not so much on the Revolutionfr list ;-<) 
-- one may add some vivid french speaking web sites to the new section!

-- 

___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Slightly OT: Thanks to Frank and Mark

2005-02-08 Thread graham samuel


I owe Frank D Engel Jr and  Mark Talluto thanks for answers to daft 
questions of mine (Network Hell and Re: image contrast and brightness). 
Frank, I'm starting on your network references right now- looks like a 
life saver. And I've ordered the book you recommended, Mark.

And as to your ref to RevOnline:
That looks like a ref to a RevOnline user space.  If you are not
running 2.5, download the free Dreamcard Player to gain access to the
user spaces; if you are running 2.5. click the "Rev Online" button on
the toolbar.
I have to say that I'd forgotten about RevOnline because although I'm a 
2.5 user, I've been on a very slow dialup link for quite a time and 
really didn't want to go there (and if you think that's bad, try using 
iDisk with a 28Kbaud connection...). However the French government has 
just fulfilled its promise in my corner of rural France to provide us 
all with broadband, so things will be different from now on.

Back to work - my next post will actually be about Rev.
Graham

Graham Samuel / The Living Fossil Co. / UK and France
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Ultra Beginner Question/Request

2005-02-08 Thread 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 m

54 matches

Mail list logo