Sami, Jim,
Unfortunately, I won't be at the conference - as much as I would like to be I
simply cannot afford the trip from the UK.
I did, however, discover something interesting last night when I had time to do
some experiments:
First off, Sami, I tried your suggestion of browsing all the columns by name
from the R:> with SET LAYOUT ON. I then changed the default cell depth from 2 to
1 for one column, exited and re-ran the same command - still came back with a
depth of 2.
I repeated this for each of the three columns in the table - 2 are integers and
the other is text. I half expected that if I changed the text column maybe that
would work - even though the message on the amend screen indicates that changing
one column would affect all. I was wrong, there was still no difference and
going back each time I still got a depth of 2.
By chance, I then resorted to the on-line help for EDIT and discovered that you
can set both the depth and the width of each column by using "ColName=1=30". Of
course, this works - giving one row 30 units wide . But the layout is still not
saved.
So, I have a work-around: I can create a menu of commands that allows me to edit
the tables in the column sequence, row depth and row width that I want. But
you've probably guessed what comes next: I don't like it!! It's far too
complicated. I'm used to the old Dos browser where I could use [Ctrl][F3] and
mark/unmark columns and add/remove conditions in a flash. I don't know which
combinations I'm going to want so a menu of commands is workable but not
convenient.
As an aside, I hadn't consciously noticed it before, but in Dos the default cell
depth is two. With save layout on, as expected, when changed to one it is saved
with a depth of one.
I didn't think that I was going to like the Object Manager in Windows - but I
do. It's not as quick as some of the Dos ways of doing things but it's much
easier in other ways. Already I've got to like editing/browsing from there -
especially as I test things and check the data that is converted. However, I
think that the layout as displayed, if saved, should be saved wherever it is
saved from. To me, this was one of the great strengths of R:Base for Dos - any
old fool could get the data they wanted in the browser easily with a few
key-strokes and refine it in terms of selection and display until they were blue
in the face. No need to even type at the mighty R:> if you didn't want to!
I seem to remember somebody else on this list having a similar problem getting
the columns saved in their preferred re-arranged order which is why I mentioned
in my earlier post that I had overcome this by locking certain columns - but
this only works for the displayed area of the screen according to the help
files.
Jim's comments about edits not being saved correctly is also worrying but I
haven't noticed it myself. I think that I have added and deleted rows from the
browser/editor without that problem in W6.5++ - although I have had R:Base crash
more than once when attempting to edit by pressing [F4]. This seems to happen
with my larger tables but I'm not sure of that.
All I can suggest here is that maybe it is linked to the user in some way. In
the Dos version my SYS_LAYOUTS table used to get corrupted quite easily. I never
found any reason for it so I could never really find anything to report to
Microrim/RBTI and just put it down to "one of those things", although I think I
did mention it here on this list some time ago. It was also easy to correct:
delete the rows and re-save the layouts - a bit of a pain but workable. The
other thing that I have noticed is that I don't seem to get the message about
reverting to the default layout which often used to appear in Dos after changes
were made. Perhaps I just have not created the circumstance where it should
appear but maybe there's a clue there.
Presumably, there is now an added complication of users identified by name as
well as password. I am still using my old Dos owner password as my way into the
system but I suppose I ought to change that to a username and password. Perhaps
inserts/deletions are controlled by the system in such a way that a saved layout
linked to a user and/or password has some strange effect under certain
circumstances. It's not too hard to accept that if the displayed sequence of the
columns is not the same as the table sequence then the system has to do some
re-arranging before adding a row so perhaps there is a circumstance where this
fails.
Just a few thoughts in case it helps...
Regards, Alastair.
