Looking for suggestions in editing FilePro files

[Fairlight]

Confusious (Richard Kreiss) say:
> Mark,
> 
> This sounds interesting.
> 
> May we assume(bad word) that all other types of editing functions would be
> available?

Well, it's going to be a real GUI if it's done.  What I did in my
other program was make it very Excel-like.  You could navigate with
tab/shift-tab, arrow keys, and return.  Editing a cell was triggered with
F2, as is standard in Excel, or with right-click.  I can pretty much bind
edit to whatever I want.  When you're in a cell, well it acts just like a
normal GUI Excel or other spreadsheet cell would.

If you mean things like shrink/grow...why, yes, I already actually have
logic in place in the weapon editor for insert/delete row, so that's
actually already programmed, now that I think of it.

Overwrite vs insert is a bit different, as is cursor placement.  Because I
bound Insert and Delete to do those operations to rows, currently those
keys are not actually usable inside a cell even while editing.  Nor are
arrow keys.  You can right-click to initiate edit of a cell as well, and
right-click again to a specific location within a line and backspace,
however.

I could re-bind "shrink/grow" to F3/F4, thus freeing up insert/delete keys
to (I presume) their normal functionality.  Arrow keys could be unbound
from navigation until editing is finished by enter, tab, or shift-tab,
although that's very un-spreadsheet-like, which is why it wasn't done in
the first place in what I wrote.  Actually, I suppose Insert/Delete could
stay as they are and I could just bind F1 and F2 like they are in *cabe.

Most of what's needed in terms of the actual ability to keep cells from
being editable (If, Then, and Label labels), navigation, and shrink/grow is
all there already.  Essentially I'd need to rip the GUI apart a bit, cut
out a side pane that isn't needed right now, rework the row system to be
"dual row" like *cabe is, change what columns are editable, redimension the
window, etc.

Ooh, added bonus...what I have already has a 10-file quick-load history in
place, similar to many programs, where File->0-9 will load one of the files
from that history.  That's already there.

Actually, what I have for the weapon editor -may- be interesting in a
filePro editor...  In editing weapons, the server admins wanted to be able
to look at current weapon definitions while they work on their modified
weapon.  So what I have right now is a dual-pane setup that allows you to
edit one file properly, while locking a second file to a view-only second
file for comparison.  The current screen layout would actually -lose- space
over *cabe* at 1024x768 with a 10pt font, because the panes are one above
the other.  If I restructured it so that you had total top-to-bottom panes
for each file, and make the window screen-wide, I could put the panes side
by side instead of stacked vertically, which should give you more viewable
lines -and- the ability to compare.

Handling line lengths should be doable.  When editing of a cell is
finished, a callback function could truncate the contents to the
appropriate length.  Alternately, it could leave the contents alone, but
just raise a warning window or put a status indicator somewhere else that
the cell contents are too long.  I'd need -exact- details on the
limitations there, as I seem to recall that it's not just that If and Then
are limited to certain lengths, but rather that there's an editing
limitation in *cabe per segment, but things will actually still -run- if
the -combined- length of both segments is under a certain size.  The
details on that have always been a bit hazy.  Given accurate information,
it's workable one way or another.

If you want to see what I'm talking about as far as what I have, so you can
see how it could be adapted, hit www.fairlite.com, and look at the 8/17/08
entry in the events.  Click on the first of those three images of programs.
The first one is the weapon editor in question.  I'm talking about ripping
out the completely graphical decorative pane on the right, making the app
fullscreen (I can get desktop geometry, so it would work in any resolution
as a maximised size), moving the bottom red/pink (read-only comparison
file) pane to the right hand side of the app, and extending both the green
and red panes from top to bottom.  The status area would probably stay,
although I could be persuaded otherwise--I'd just have to rewrite my status
update logic to pop up windows when things go astray and warnings/errors
are needed.  Personally, I'd rather keep it there--maybe a compromise and
put it -only- on the right hand comparison side, and give full vertical
real estate to the green current editing file.

Just a thought of what's possible...

One thing I just thought of that would be a bit trickier...I don't have any
current code that would serve as a lookup wizard.  Not even sure how many
hardcore devs use the wizard anymore.  That, and looking up fields from the
current and other files would have to be added (that whole F6 thing)--and
even then, I think I'd only grab real fields off the map, and there's no
way I'd bother grabbing dummy fields.  I'm not out to reinvent the syntax
parser, here, so it would only be made to go so far.

I'd need to be commissioned to make this editor happen.  I did FairView,
that image viewer that was meant for filePro use, on spec...and I've sold
exactly one copy in like five years or something.  $49.95 for $7200+ in
development time.  Nuts to that.  If I'm working on something, it'll have
to be contracted.  No more on-spec for me.  I might work out a discount
on development in exchange for non-exclusive, so that I could resell it,
but it wouldn't be that steep a discount.  It would also run in the mid
4-figure range for development.  I'm sure it's over 50hrs of redesign and
addition of features, easily--probably more.  Guess it just really depends
how much someone wants something like this.  Sounds high for what we're
talking about, given that fP itself is "only" 1500 for a 5-user devkit,
but we're essentially talking custom stuff here.  Custom costs, period.
And like I said, my on-spec for-presumed-resale days are pretty much done.
Never say never, but I don't intend to go down that road again.  That road
is filled with flame and accellerant, and features a full-sized blast
furnace at the end of the line.  :(  Honestly, it's gotta be worth the time
spent not working on other things, or it's not getting done.

But some people -really- want something sometimes.  Doesn't hurt to put it
out there if you can make something happen.  Strange things happen.

> If I am recalling correctly, there is a 126 character or something like that
> line restriction. Would you be able to lock each cell so that it takes the
> correct number of allowable characters?

It's possible to do it the way I said above (post-edit), or I believe I can
bind to key-up and handle the logic there as well, preventing you from
typing further.  Either would probably work.

> I am sure Ken or someone else will correct me if I am wrong.

I don't think you're wrong, so much as I think the situation was a bit more
complex than depicted.

mark->
-- 
Audio panton, cogito singularis,