I've just uploaded a (slightly cheeky) tutorial on how we've done
tabbed dialogs using DesignBais. You'll find it in the uploaded files
section of this forum. Please let me know if you're having trouble
getting at it.

Regards,
Jeff

Now _that_ is very clever!  What you're doing in PAINT.TABS.SUB is really
great.  And I was just telling my wife today that people aren't really
taking advantage of the cool things you can do with CSS in DesignBais.
Wow, I'm glad to be wrong!  :)

Congrats Jeff!
T

I have played with Jeffs tabs and they are very cool.  Give them a
try, you won't be disappointed.

Great job Jeff,

Rick

On Sep 21, 2:44 am, "Tony G" <1f6xum...@sneakemail.com> wrote:

Hi Jeff,
I'm a bit of a slow learner, so my questions may appear strange; but I
like the idea of this and what to get my head around it all.

When reading your pdf for the first time, I [incorrectly, I think]
assumed that the file TAB.CONTROL was going to contain the "Soft"
wording of the Tabs. In which case I started looking for READs of that
file, and the corresponding key to make it more generic. I couldn't
find any; and then realised that the text was sitting in the
subroutine HANDLE.TABS.SUB. Given the way your worked example
functions; would that mean a real application with "n" forms which
required tabs; would need "n" subroutine instances of HANDLE.TABS.SUB?
This being the case, wouldn't that become a problem with multiple
languages, as you would need a specific subroutine for each langauge/
form combination?

Or did I miss something here?

It seems to me, that the only reason for the existence of the file
TAB.CONTROL is to create the equates necessary for all the subroutines
to run and for db to use for DBOTHER.RECORD(90); the file actually
doesn't contain anything.

Have I got that right?

If so, wouldn't it be more flexible if the TAB.CONTROL file actually
contained the text of the tabs for a given form? In which case the key
to this file could be the form name? This would allow the tab
descriptions to be "soft" and also allow for more easy translation
into other languages.

Or does this entire post just show that I cannot understand another
person's code?

David Knight

On Sep 21, 1:24 pm, Jeff <jw.gro...@gmail.com> wrote:

Hi David,

HANDLE.TABS.SUB was really just written as a proof of concept, so your
comments are right on target. If you were going into production with a
lot of forms you'd definitely be populating your tab names more
elegantly. You could do a lot of things to generalize this approach,
including replacing your "AFTER DISPLAY" a more general subroutine
that calls PAINT.TABS.SUB, automating the reads, etc. I certainly
didn't mean to suggest best practices for overall form design.

My focus was pretty much just on demonstrating a CSS-based approach to
rendering a more graphically pleasing tab header and showing how a
single field object (the TABS field) could be wired to "n" different
event handling objects on the form (the B.TABn buttons). When I get a
chance I'll submit a "Version 2" with more of a table-driven approach
to tab names. I've also been considering an "extended play" section
that expands on the section logic, the style sheet approach itself,
and the dependencies this design has on DesignBais ASP code.

Regards,
Jeff

Hi Jeff,
Thanks for the reply. At least I am glad that I understood the basics.
I really like the idea, and want to suggest some things [in a moment],
but my more pressing issue is whether we should be tinkering with this
stuff in the first place. I have an email to db pending which
basically asks the question: "Is this a wise avenue for a developer
using db to follow in respect of future directions db may take?" It
seems to me that we are fiddling with the internals of a form; which
relies upon db not changing [at least] that section of their form's
internal structure. Are we playing "god" in the db universe? I would
welcome others views upon this issue.

Now, to the example you gave [which I respect was never designed to be
"perfect"]. While I agree with code compartmentalisation, I do not
understand why this is 3 subroutines when it seems to me all 3 only
ever function together, and would be unlikely to be required as
sections on their own. In which case, couldn't they all be wrapped in
single s/r? Further, if we add a key and attr 4 to the "Tab Control"
file; where attr 4 is [say] "Tab_Text" as a multivalued alphanumeric
field, and the key has the same structure as the key built in
GET.HTML.ELEMENT.ID, that is, the key to the DBIFORMS file?

A simple data entry screen could be built to allow population, [and
possibly alteration by the end user] of the description of the Tabs
for a given form. Attr's 1-3 would remain blank as is currently the
case as they are really just place holders for the subroutine to use.
For those who are really sticklers for not wasting hard disk space;
this new amc could become 1, with the previous amc's 1-3 shifting down
one; seeing as they are always empty.

Then since the subroutines are all one, and the tab text is held in a
record keyed the same as the currently run form, then couldn't it also
be read in the CASE section for "After Display" and placed into
DBOTHER.RECORD(GFA.TAB.CONTROL) with appropriate syntax changes
elsewhere in the routine to use the resulting set of mv text tags
instead of TAB.NAMES?

Wouldn't this then become a generic subroutine that "hacks" db so that
it displays tabs?

Comments, anyone?

Best wishes to all,

David.

On Sep 25, 2:56 am, Jeff <jw.gro...@gmail.com> wrote:

Hi David,

You're quite right that this has dependencies on three assumptions:

1) the structure of DBIFORMS records won't change

2) a subroutine in the client-side ASP called "raiseBAEvent" will
continue to exist and behave essentially the same way

3) "raiseBAEvent" will continue to rely on the "name" property of a
given HTML element

Note: I don't think of this as a "hack" of the form since nothing
created by DesignBais is actually changed. It does, however, rely on
the assumptions listed above. Is this risky? Perhaps. That's why I
chose to contact DesignBais long before I wrote this up. If I'm forced
to play "god" to get standard HTML forms to do standard HTML-y things,
then I should probably also attempt to influence the real supreme
entity in future decisions. This was my third attempt at creating a
tab header. My first attempt followed their recommendations in an old
PDF (the graphics example). My second used injected javascript and it
was fine in standard mode but behaved a bit oddly in MODAL or LAYERED
mode. My third attempt you're looking at.

I sometimes use the GET.HTML.ELEMENT.ID routine for other purposes. As
for PAINT.TABS.SUB, it makes sense in our current application to carve
this subroutine off. Each of our forms generally has its own event
handling subroutine (not my design, but I'm still working to influence
the supreme entities here at home too) so it helps to have a shared
routine for those event handlers too call.

As for the rest of your optimizations, I heartily recommend refining
my very dull ore into your own shining jewel. You have excellent
suggestions and I'd like to see the outcome if you're willing to
share.

Regards,
Jeff

Rather than getting verbose on the topic here as I usually do, I just got
verbose on it in my own blog where I've discussed this topic before. :)

remove.this.pleaseNebula-RnD.com/blog
See article: "Is it OK to Extend DesignBais?"

HTH
Tony Gravagno
Nebula Research and Development
Worldwide sales and development services for
DesignBais, and other developer tools
TG@ removethisNebula-RnD.com