[thelist] List Archive Etiquette Tip

[Luther, Ron]

Hi Gang,

Since I read my evolt mail in Outlook, (which nicely wraps any
extended paragraphs - as do some other mail readers), I forget
about folks who may be catching up on things by browsing the
list archives - where extended paragraphs cause really really
ugly scrolling to the right!

Since it's been brought to my attention, I'll try to stop doing
that, but I thought I'd also share it as a tip.


<tip type="list archive etiquette" author="RonL.">

Try typing in shorter lines or inserting some line
breaks or carriage returns into your posts.

Folks browsing the list archives will find them easier to read.

</tip>



<tip type="Brio 6.5: Multiple radio buttons checked? Blame
event bubbling" author="RonL.">

Sorry this is a little long - it's kind of a subtle problem/bug.

If you have an OnActivate script in a section that sets a default
radio button, your OnClick processing event may get fooled into
thinking multiple radio buttons have been checked.  Here's how:

Suppose button 1 is your default checked radio button.

Suppose the user checks button 2 and that your processing script
looks like this:

{
if (RadioButton2.Checked) {
    Run a Query;
    Do Some Stuff;
}

if (RadioButton1.Checked) {
    Run a Different Query;
    Do Some Other Stuff;
}

}

Here's what happens ... the user checks button 2 and hits your
'process me' command button so the 'button 2' portion of your
script runs.

Now, since the 'button 2' portion of your script contains a
database call that may take some time to execute, Brio goes
ahead and "bubbles up" the command button event to trigger the
OnActivate script!

{Yup - before it finishes your processing! Neat "feature" eh?}

<prayer>
Lord, deliver me from "smart" applications!
</prayer>

Now, if you remember, your OnActivate script sets the default
radio button by _checking_ button 1.

Once the database query executes, the original script will
continue to process, but, since your default button is now
checked ... you *are* going to trigger the portion of your
script that processes 'button 1' requests.

I think this is a fairly serious bug in the software.
A bug that can be a little tough to diagnose!


Work-Around:

If you *always* place your scripting for the default button
at the top of your processing script, you should get the
behavior you expect.

</tip>