pilot-db-list

[pilot-db-list] fixed sorting on date/time fields

[Tom D. <td...@us...>]

ftp://pilot-db.sourceforge.net/pub/pilot-db/dbtest-en.prc
ftp://pilot-db.sourceforge.net/pub/pilot-db/dbtest.tar.gz

Changes from last time:

- Fix sorting on date and time fields. (Forgot to initialize a variable ... 
ho hum)

Re: [pilot-db-list] truncated relocations

[Andy R. <an...@wi...>]

On Wed, 24 Jan 2001, Greg Alt wrote:

> On Wed, 24 Jan 2001, Andy Rabagliati wrote:
> > 
> >   However, I get >32k jump link errors, as follows :-
> 
>   If you haven't installed update 1
> to the SDK3.5, then that should fix it.

I checked again - I have installed the update - thanks.

I am using linux.

I get 6 errors total, and it is a >32k jump error.

I think that by tweaking db.def I could get better results,
but I was just checking that other people could compile,
and that what is in CVS is all fully updated.

db.def says :-

-------------------------------------------------------
application { "DB" DBOS }

multiple code { "foo" "editsect" "gridsect" "drvsect" }
-------------------------------------------------------

Cheers,     Andy!

[pilot-db-list] RE: new test release (Tom Dyas)

[Fab <kr...@bi...>]

> Be careful with this release since the date/time support is new development 
> and was just added.

	I use this version since yesterday. Thanks to you, it's pretty
cool. I have some feedbacks :

	* The sort command crashes the palm when a date fied is involved
in the sort keys (fatal exception).

	* db-tools is not aware of the new field types. So my scripts
to get the base in text format and modify it on the computer don't work
anymore. No matter, I can wait.

	* In the meantime I decided to take a look at the jf3 db format.
It appears I get a fatal error each time I try to create a base on the palm.
The crash appen before creating the real base, so after that I get the base
name but the file doesn't exist. I can create the base in csv format, convert
with db-tools and download it onto the palm, and then it works.

	I'm sorry to just point out the problems and not dig into the code,
I'm trying just now to configure my linux box, but I can't get db to compile
on it... Just a matter of time :-)

	Fab.

	

Re: [pilot-db-list] truncated relocations

[Greg A. <ga...@es...>]

On Wed, 24 Jan 2001, Andy Rabagliati wrote:
> Tom,
> 
>   I follow your db project on Sourceforge, by checking the latest version
>   out of CVS.
> 
>   To compile, I need to specify the SDK version, and add a library path.
>   I have a slightly different placement for libraries, so the -L may
>   be my issue, and ditto for the default SDK.
> 
>   However, I get >32k jump link errors, as follows :-

I think this is the same problem I had.  If you haven't installed update 1
to the SDK3.5, then that should fix it.  If that works, but then build-prc
spits out a bunch of errors (the same one 50 times), the problem is that
you need to upgrade prc-tools to 2.0.90 (2.1pre1).  If you are using
Windows, I don't think there is a windows binary of that yet, but a simple
workaround is to just move all the .bin files from .res to the main db
directory.

Greg

[pilot-db-list] truncated relocations

[Andy R. <an...@wi...>]

Tom,

  I follow your db project on Sourceforge, by checking the latest version
  out of CVS.

  To compile, I need to specify the SDK version, and add a library path.
  I have a slightly different placement for libraries, so the -L may
  be my issue, and ditto for the default SDK.

  However, I get >32k jump link errors, as follows :-

m68k-palmos-gcc -L/opt/palmdev/sdk-3.5/lib/m68k-palmos-coff -o db db-sections.ld db-sections.o main.o list.o chooser.o design.o
io.o util.o listprop.o prefs.o find.o linkaware.o grid.o edit.o sort.o names.o MobileDB.o JFile3.o -lPalmOSGlue
/opt/m68k-palmos/lib/crt0.o(.text+0x50):crt0.c: relocation truncated to fit: DISP16 __do_bhook
[...]
db-sections.o(.text+0x2):db-sections.s: relocation truncated to fit: DISP16 _GccLoadCodeAndRelocateData
/opt/m68k-palmos/lib/libcrt.a(hooks.o)(.text+0x16):hooks.c: relocation truncated to fit: DISP16 start
[...]
collect2: ld returned 1 exit status


  I have tried other optimisation and debug options, to no avail.

  Is the version in CVS what you use to build ?

Cheers,  Andy!

cvs server: Diffing .
Index: Makefile
===================================================================
RCS file: /cvsroot/pilot-db/db/Makefile,v
retrieving revision 1.25
diff -r1.25 Makefile
13c13
< CFLAGS=-Wall -O2 -g
---
> CFLAGS=-Wall -O3 -palmos3.5
16c16
< LDFLAGS=-g
---
> LDFLAGS= -L/opt/palmdev/sdk-3.5/lib/m68k-palmos-coff

[pilot-db-list] new test release

[Tom D. <td...@us...>]

ftp://pilot-db.sourceforge.net/pub/pilot-db/dbtest-en.prc
ftp://pilot-db.sourceforge.net/pub/pilot-db/dbtest.tar.gz

Changes:

- Date and time field types.
- Changed design view partially to use the context menu method of adding and 
removing fields. (Still need to let you drag the rows to reorder fields in 
the design.)
- JFile v3.x support (most of the field types but not list field types and 
popup stuff)
- Greg Alt's bug fix for rightmost columns being clipped.

Be careful with this release since the date/time support is new development 
and was just added.

re: [pilot-db-list] Plans for filters?

[Nathan K. <na...@va...>]

Greg Alt <ga...@es...> writes:
> 
> What I envision is something like the different list views, where you can
> create different filters each with a different name, and then you can
> select one to perform that filter.  The default would be an empty filter
> that just let's everything through.
> 
> When editing a filter, you would be presented with a screen very similar
> to the sort screen.  Something like this:
> 
>     op cs Field value     Field
> *   <  x  ____________  * field name
> 
> 
> Clicking on the first * would give you a pulldown letting you insert
> another filter line.  Clicking on the op field would give you a pulldown
> letting you choose a filter operation (<, >, =, <=, >=).  The field name
> would be chosen just as for Sorting, and the field value is the value to
> perform the operation to filter against (so, <= for a date field would
> select all records with the date field showing a date before or on the
> specified date).  

A few months ago, I spent some time thinking about how filters could
be done, and came up with essentially the same approach.  Then I got
distracted by trying to fix GDB/prctools and didn't come back to it.
But somewhere I've got a lot of scribbled scrap papers with 'screen
shots' virtually identical to this.  Which is to say, I like it.

I was picturing infix notation instead of prefix: [FIELD op (value)]
instead of [op (value) FIELD].  Did you grow up with using HP's
reverse-polish-notation calculators, by any chance? <smile>

Inserting fields seems good.  I was thinking of just having one button
to add a new line at the end, but insertion might be more useful.
Being able to delete lines might be good, too.

I feel that sorting and filtering should be combined---at least so
that when one searches by a field the search results are displayed
sorted by that field.  Perhaps this requires an 'reverse' checkbox.

> Then, when you select that filter, each filter operation is essentially
> ANDed together.

Strong agreement.  Small, simple and intuitive.  Support for
generalized Boolean queries might be nice, but could be added later.

> For now, filters could be selected the same way list views are now (go to
> the display menu option and have pulldowns for both view and filter).
> Later, support could be added for named reports that specify both a view
> and a filter -- then you just click the report you want and it shows it
> with one click.

I'd wonder if there is room for this at the bottom of the View screen,
replacing some of what is already there.  One can tell at a glance
what View one has; I think one should be able to see what Filter is in
effect as well.  I also think that easy filtering could supplant Find.

I agree with named reports, and think this could be handled under the
existing Views.  Each View could have a default filter, which could
then be changed from within the View.  Default filter is 'none',
sorted by column order.  Multiple views with identical fields but
different filters could account for the features of named reports.

> Any comments, improvements, alternatives?

Sounds great to me!

--nate

Re: [pilot-db-list] Plans for filters?

[Nathan K. <na...@va...>]

Tom Dyas writes:
> 
> While this setup is similar to the sort screen, how would paranetheses be 
> handled and also OR and NOT? The "DB way" is to do things as generically as 
> possible. Maybe a hybrid of the above view with the following:
> 
> The top of the view is a text field listing the current filter in some sort 
> of "expression syntax" like: "Name = 'Tom' AND (Age <= 18 AND Age >= 65)". 
> And then the bottom half is like what you described providing some sort of 
> editable line-by-line description of the expression:
> 
> op    Field       Value
> =      Name      Tom
> AND n/a          n/a
> (       n/a          n/a
> <=    Age         18
> OR    n/a         n/a
> >=    Age         65
> )      n/a           n/a
> 
> This would still need some more refinement but it would allow any sort of 
> expressions.

While having full appreciate for the power of generality, I think this
would be too complex to work well.  At the least I would suggest
starting with the simpler Boolean free interface (implicit AND) and
then later adding the generality once everything is working.

Of course, maybe I'm wrong.  I feel like the sorting is very
important, and perhaps it is not.   I feel like the Filters should be
present within the View, but I suppose they need not be.

> As for implementation, the best place to write the code which
> actually filters the list view would be ViewModel_Seek() in list.c
> which actually decides what records make it into the list
> view. (Currently, it just asks the data source for the next record,
> but it would be changed to ask for the next record and then apply a
> filter.)

Because I value the sorting, I figured that it would be better to
perform the query and then save the results somewhere where they can
be sorted (QuickSort) in advance.  Thus, I'd picture another
datasource rather than putting the filter logic into the list display.

--nate

Re: [pilot-db-list] Plans for filters?

[Greg A. <ga...@es...>]

On Fri, 19 Jan 2001, Tom Dyas wrote:
> If you make a SourceForge account, I can add you to the pilot-db project 
> which would give you the ability to commit changes to DB w/o needing to send 
> them to me. (This applies to anyone who wants to contribute more than a small 
> patch of code. The more active developers, the merrier.)

thanks.  I'll get that set up and get back to you.

> While this setup is similar to the sort screen, how would paranetheses be 
> handled and also OR and NOT? The "DB way" is to do things as generically as 
> possible. Maybe a hybrid of the above view with the following:
> 
> The top of the view is a text field listing the current filter in some sort 
> of "expression syntax" like: "Name = 'Tom' AND (Age <= 18 AND Age >= 65)". 
> And then the bottom half is like what you described providing some sort of 
> editable line-by-line description of the expression:
> 
> op    Field       Value
> =      Name      Tom
> AND n/a          n/a
> (       n/a          n/a
> <=    Age         18
> OR    n/a         n/a
> >=    Age         65
> )      n/a           n/a
> 
> This would still need some more refinement but it would allow any sort of 
> expressions.

That sounds good, but it might be a bit too complex, having to match
parentheses.  What if explicit parentheses weren't supported, but you
could do any expression of this form:

   (a && b && !c) || !(d && !e) || f || !g

but not expressions like this:
   a && (b || c)

which could instead be done as:  (a && b) || (a && c)
 
With that limitation, you could just assume that all lines are ANDed
together.  If you wanted to OR things together you could add a line at the
top of the group.  If there is more than one group, the groups would be
ORed together.

NOT could be added as a checkbox for each line, including the group
operator.

On the upside, this would simplify the interface, though the downside is
that it would be a bit awkward to do: a AND (b OR c)

hmmm... actually, I could see that as being a big problem, because it
might actually be common to have an expression like:
  a && b && c && (d || e || f)

which would be a mess in the system I just described.

Maybe if it was how you described, but ANDs could be implicit and have
precedence over OR -- so you could do this:

=   name   bob
<=  age    23
OR
=   name   fred
>=  age    21

without the extra six lines for parens and ANDs.  That way parens would be
optional and explicit ANDs would be unnecessary.

also, if there was a NOT checkbox, you could check it for individual field
tests or for a whole () group.

> Actually, while having the dialog to control the list view and filter at the 
> same place, it might be good to have the active filter be in a 
> category-selector control in the top right of the list view since it is a 
> generic version of categories. Or maybe the named reports would be better in 
> the top-right corner.

It all depends on how often you'd like to look at the same data in
different views or different filtered data in the same view vs. having the
filter and view linked together.

If you have 5 different views and 5 different filters, and you like to
switch between all of them, then creating all 25 possible reports and
having to choose from them would be unwieldy, but if you tended to use a
specific view with each specific filter, then you'd probably prefer
clicking once to select from 5 reports rather than having to select both
view and filter.

Greg

[pilot-db-list] answers to various questions

[Tom D. <td...@us...>]

The forwarding from td...@us... to my real email was screwed 
up so I missed some questions. But looking in the archive here are answers:

compiling development versions:

Read the file docs/building.txt in the source code. It documents everything 
that is needed to build DB from scratch. Currently, prc-tools 2.0.90 
(2.1pre1), SDK 3.5update1, and pilrc 2.7a are required.

binary versions of 0.3.1:

0.3.1 is still under development so I will try and make compiled versions 
available as frequently as I can but it won't be as often as compiling DB 
yourself.

improving LinkMaster support:

I have no real plans to improve the LinkMaster support right now. This is not 
to say that I am against other people improving it. I just don't have time.

re: [pilot-db-list] Found a bug, found a fix, what's the procedure?

[Tom D. <td...@us...>]

> Create a view with 3 fields, widths 80, 70, 80.  Switch to that view.
> You'll see the first two fields and a tiny piece of the 3rd, but the
> scroll right button is missing, making it impossible to scroll to see the
> full 3rd field.
>
> This is a general problem if the right-most column is clipped.
>
> Here's a patch that fixes it:
>
> [patch here]
>
> Also, this raises the question, what is the general procedure for
> submitting bug fixes and new features?

For small fixes, I'll just apply the patch. For larger stuff and/or more 
frequent contributions, make a SourceForge account and I'll give you access 
to the source code via CVS.

Also, could you add the -u option to the "cvs diff" command and resend the 
patch? It is easier to see what changes with unified diff output.

Thanks for spotting that bug.

Re: [pilot-db-list] Plans for filters?

[Tom D. <td...@us...>]

On Friday 19 January 2001 17:53, Greg Alt wrote:

> I noticed that filters are mentioned on the TODO list.  Has work begun on
> that yet?  If nobody else is working on it, I have some ideas for a system
> that fits with the conventions used in DB, and I'm ready, willing, and
> able to get to work on it.

If you make a SourceForge account, I can add you to the pilot-db project 
which would give you the ability to commit changes to DB w/o needing to send 
them to me. (This applies to anyone who wants to contribute more than a small 
patch of code. The more active developers, the merrier.)

> What I envision is something like the different list views, where you can
> create different filters each with a different name, and then you can
> select one to perform that filter.  The default would be an empty filter
> that just let's everything through.
>
> When editing a filter, you would be presented with a screen very similar
> to the sort screen.  Something like this:
>
>     op cs Field value     Field
> *   <  x  ____________  * field name
>
>
> Clicking on the first * would give you a pulldown letting you insert
> another filter line.  Clicking on the op field would give you a pulldown
> letting you choose a filter operation (<, >, =, <=, >=).  The field name
> would be chosen just as for Sorting, and the field value is the value to
> perform the operation to filter against (so, <= for a date field would
> select all records with the date field showing a date before or on the
> specified date).
>
> Then, when you select that filter, each filter operation is essentially
> ANDed together.

While this setup is similar to the sort screen, how would paranetheses be 
handled and also OR and NOT? The "DB way" is to do things as generically as 
possible. Maybe a hybrid of the above view with the following:

The top of the view is a text field listing the current filter in some sort 
of "expression syntax" like: "Name = 'Tom' AND (Age <= 18 AND Age >= 65)". 
And then the bottom half is like what you described providing some sort of 
editable line-by-line description of the expression:

op    Field       Value
=      Name      Tom
AND n/a          n/a
(       n/a          n/a
<=    Age         18
OR    n/a         n/a
>=    Age         65
)      n/a           n/a

This would still need some more refinement but it would allow any sort of 
expressions.

As for implementation, the best place to write the code which actually 
filters the list view would be ViewModel_Seek() in list.c which actually 
decides what records make it into the list view. (Currently, it just asks the 
data source for the next record, but it would be changed to ask for the next 
record and then apply a filter.)

> For now, filters could be selected the same way list views are now (go to
> the display menu option and have pulldowns for both view and filter).
> Later, support could be added for named reports that specify both a view
> and a filter -- then you just click the report you want and it shows it
> with one click.

Actually, while having the dialog to control the list view and filter at the 
same place, it might be good to have the active filter be in a 
category-selector control in the top right of the list view since it is a 
generic version of categories. Or maybe the named reports would be better in 
the top-right corner.

[pilot-db-list] Plans for filters?

[Greg A. <ga...@es...>]

I noticed that filters are mentioned on the TODO list.  Has work begun on
that yet?  If nobody else is working on it, I have some ideas for a system
that fits with the conventions used in DB, and I'm ready, willing, and
able to get to work on it.

What I envision is something like the different list views, where you can
create different filters each with a different name, and then you can
select one to perform that filter.  The default would be an empty filter
that just let's everything through.

When editing a filter, you would be presented with a screen very similar
to the sort screen.  Something like this:

    op cs Field value     Field
*   <  x  ____________  * field name


Clicking on the first * would give you a pulldown letting you insert
another filter line.  Clicking on the op field would give you a pulldown
letting you choose a filter operation (<, >, =, <=, >=).  The field name
would be chosen just as for Sorting, and the field value is the value to
perform the operation to filter against (so, <= for a date field would
select all records with the date field showing a date before or on the
specified date).  

Then, when you select that filter, each filter operation is essentially
ANDed together.

For now, filters could be selected the same way list views are now (go to
the display menu option and have pulldowns for both view and filter).
Later, support could be added for named reports that specify both a view
and a filter -- then you just click the report you want and it shows it
with one click.

Any comments, improvements, alternatives?

Greg

[pilot-db-list] Pilot-DB 0.3.1 & LinkMaster

[Larry K. T. <LK...@we...>]

It would be nice to be able to publish a LinkMaster link for a specific =
View, especially now since you can have multiple views.


Larry

[pilot-db-list] Pilot-DB 0.3.1

[Larry K. T. <LK...@we...>]

I have DB 0.3.1 on my Palm, but I can not find the binary files on =
SourceForge.  Anyone know where I can get a copy.

Larry

[pilot-db-list] Found a bug, found a fix, what's the procedure?

[Greg A. <ga...@es...>]

I found a little bug:

Create a view with 3 fields, widths 80, 70, 80.  Switch to that view.
You'll see the first two fields and a tiny piece of the 3rd, but the
scroll right button is missing, making it impossible to scroll to see the
full 3rd field.

This is a general problem if the right-most column is clipped.

Here's a patch that fixes it:

RCS file: /cvsroot/pilot-db/db/grid.c,v
retrieving revision 1.6
diff -r1.6 grid.c
56a57
>     Boolean rightcolumnclipped = false;
65c66
<       if (width > grid->bounds.extent.x - x)
---
>       if (width > grid->bounds.extent.x - x) {
66a68,69
>           rightcolumnclipped = true;
>       }
94c97
<     e.data.generic.datum[2] = (grid->rightColumn < grid->numCols - 1);
---
>     e.data.generic.datum[2] = (grid->rightColumn < grid->numCols - 1 || 
rightcolumnclipped);


Also, this raises the question, what is the general procedure for
submitting bug fixes and new features?

Greg

[pilot-db-list] Re: Pilot-db-list digest, Vol 1 #103 - 2 msgs

[Fab <kr...@bi...>]

> Good luck!  It's a pain in the ass figuring out how to get it to work, but
> it should be just a few simple tweaks in the end.  Oh, you also might want
> to put a -v in the compile args in the makefile to get some more info
> about what it is trying to do...
> Greg

	Thanks a lot.
	That's a great deal of new informations.
	Fab.

[pilot-db-list] Ignore my earlier message - I got it working

[Greg A. <ga...@es...>]

I don't know what the problem was exactly, but I was building version
0.3.0 which I guess is from July.  I installed cvs and grabbed the very
latest and once I was able to get it to build correctly, it works fine.
It turns out that it is very important to make sure that you have SDK3.5
as well as update1 -- without the update, the libraries are too big and
you get link errors.

But if you have prc-tools 2.0 instead of 2.0.90 (aka 2.1pre1), then
build-prc will give you a huge stream of errors.  When I read that 2.0.90
was required for pilot-db, I went straight to the prc-tools download
section on sourceforge.   Only problem is that they don't have a windows
binary for the latest.  I searced all over the net trying to find an
up-to-date binary with no luck.  Then I started reading about what changed
in version 2.0.90.  It seems the big thing is that it lets you put all the
*.bin files in a separate directory.  After hearing that, I thought I'd
try building pilot-db again with sdk3.5/update1 and prctools2.0, but after
the *.bin files were built, I copied them from .res to the main directory
and then re-ran build-prc.  It worked perfectly, and the resulting prc
file ran fine.

Now, to help anyone having troubles getting the compile or link to work...
It looks like the only real problem is that there are some built-in
assumptions about where the files are going to be, and the directory
structure that is creatured during install doesn't necessarily match it
for some reason.  I was able to get compiling and linking to work with a
few simple changes:

- change the path so that the proper version of each executable is run.
It's important that the prc-tools version of any executable is run, so
make sure that prc-tools/H-i586-cygwin32/bin and prc-tools/m68k-palmos are
in your path before the directories of other conflicting versions.  (this
is for the windows version of the tools - I imagine the linux version
should have a similar setup).  Try 'gcc --help' to get some handy command
line options.  For example, you can do 'gcc -print-prog-name=gcc' to find
which gcc it is using, 'gcc -print-prog-name=as', 'gcc
-print-prog-name=cpp', etc. all come in handy.  Make sure it's the
prc-tools version and that your directory structure matches the path it is
trying. 

Once that works, you'll have errors about include files not being found.

- make sure that the paths for your include files matches the search paths
gcc is using.  Do 'gcc -dumpspecs' and have a close look at the file it
dumps out.  Look for '*cpp_subtarget'.  There are a bunch of entries
starting with -isystem.  That's where it defines where your system include
files can be found.  They should be something like:
-isystem %(palmdev_prefix)%(palm_sdk)/include/Core/System
Now look for '*palm_sdk' and '*palmdev_prefix'.  On mine, the prefix is
/PalmDev/ and the sdk is a complex rule that essentially boils down to
sdk-3.5
So, you put it all together and that one directory is :
/PalmDev/sdk-3.5/include/Core/System

Do the same thing for the other entries for *cpp_subtarget.
Then, do a file search for the include files that it can't find.  Chances
are they are in a directory that looks a bit like one of the above ones,
but your directory structure on your disk doesn't quite match it.  Try to
patch up your directory structure with the least number of symbolic links.  

- For missing libraries, try ' gcc -print-search-dirs' to see where it
thinks they are, and do some file searches to find where they really are.
You should be able to make one or two symbolic links that will make all of
the missing libraries be found.

Good luck!  It's a pain in the ass figuring out how to get it to work, but
it should be just a few simple tweaks in the end.  Oh, you also might want
to put a -v in the compile args in the makefile to get some more info
about what it is trying to do...


Greg

[pilot-db-list] Re: Pilot-db-list digest, Vol 1 #102 - 1 msg

[Fab <kr...@bi...>]

> Given all the trouble I had getting gcc and prc-tools set up and
> configured so that make would work and all the includes/libraries would be
> found, my guess is that somehow it included the wrong version of an
> include file or linked with the wrong version of a library or something
> like that.

	I would be pleased to help you, but it seems I'm very far
from being able to compile. I've installed the 3.5 sdk over a Debian
linux distro and all the process fails for reasons like gcc binaries
not in the right place, includes from sdk not found, etc...
	So, I'm still working for a better installation...

	Fab.

[pilot-db-list] Built DB from source, seems broken

[Greg A. <ga...@es...>]

After getting everything working to the point where I can build DB from
the source code on sourceforge and running it in the emulator and my Palm,
it looks like there is a bug in the display code (probably due to my
development environment configuration).

I start up DB fresh and click New.  It then proceeds to scroll a bunch of
text in the top line of the window (looks like field numbers and type).
If I push the scroll up or scroll down buttons, it scrolls, but only it's
all on the top line, and once it is done scrolling, it stops with the
window empty, like it all scrolled off and the last line is blank.

I'm running with the latest gcc, sdk-3.5, PalmIIIe, and the latest DB
sources as of a couple days ago.

Given all the trouble I had getting gcc and prc-tools set up and
configured so that make would work and all the includes/libraries would be
found, my guess is that somehow it included the wrong version of an
include file or linked with the wrong version of a library or something
like that.

If anyone has experienced this or has some clues what it might be or some
things to investigate, I would greatly appreciate it.

Looking forward to getting up to speed with the code and helping out,
Greg

[pilot-db-list] what's up with the code

[Tom D. <td...@be...>]

I added support for date and time fields. I'll upload a test release after I 
get some testing done.

[pilot-db-list] Re: Pilot-db-list digest, Vol 1 #99 - 2 msgs

[Fab <kr...@bi...>]

> 5. From the dialog that appears, change the category
	It works. Thanks a lot.
	Fab.

Re: [pilot-db-list] Re: Pilot-db-list digest, Vol 1 #98 - 1 msg

[Larry W. V. <lv...@ca...>]

Re: changing categories
I learned how to do just that this week -

1. Start DB
2. Find the database in its current category
3. 'Click'/Select the icon beside the database name
4. From the menu that appears, choose Info
5. From the dialog that appears, change the category
-- 
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden <mailto:lv...@ca...> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

[pilot-db-list] Re: Pilot-db-list digest, Vol 1 #98 - 1 msg

[Fab <kr...@bi...>]

> Sigh - I had forgotten about the db categories, and just last nite found
> the 'missing' databases under the 'unfiled' category.

	Hello all.

	I haven't been able to change the DB categorie. I've added my
new categories without problems, but I can't figure how to change the
categorie of a particular DB. Any idea ? TIA.

	Fab.

[pilot-db-list] Never mind about the 'missing' databases

[Larry W. V. <lv...@ca...>]

Sigh - I had forgotten about the db categories, and just last nite found
the 'missing' databases under the 'unfiled' category.
-- 
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden <mailto:lv...@ca...> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-