I have an application that changes the color of an element depending on the value of a second element.  When the CLOSED element is set to "Y", the DESCRIPTION element background changes to brown.  When CLOSED is set to "N", the DESCRIPTION element background is while.

I just noticed that when I look at a group of records that should have different background colors in Table View, the background colors of all the DESCRIPTION elements is the same as the record that was active at the time I switched to Table View.

Is this behavior inherent in Table View, or is there something I can program so the background colors will remain the proper color in Table View?

Ray, I tried your suggestion and got some really weird results.  The screen would lock up with a double image whenever I tried to go to table view.  I then tried rem'ing out the programming and put a simple writeln statement in its place.  When i did that, I got the writeln window as soon as I opened the file. 

When the writeln window opened, I got two statements (even though my writeln command only had one statement, i would get duplicates).  And every time I clicked on the screen I got two more statements and I couldn't get to the application screen.

Here's the programming I was using:

/*
If IssueClosed ="N"
{
     RGBColor(IssueClosed, 0, 0, 0, 107,255,99)
     RGBColor(BasicDescription, 0,0,0,255,255,255)
}
Else
{
     If IssueClosed ="Y"
     {
           RGBColor(IssueClosed, 0, 0, 0, 226,145,145)
           RGBColor(BasicDescription, 0, 0, 0, 226,145,145)
     }
     Else
     {
           If @IsBlank(IssueClosed)
           {
                 RGBColor(IssueClosed, 0, 0, 0, 255,255,255)
           }
           
     }
}
                       


*/


writeln("Made it here!")

Any thoughts?

It was invoking the command as soon as I opened the Retrieve Spec.  I was able to get beyond that by adding an IF statement so the ON DRAW command would only work is @MODE()=1.

I then selected only 1 record but the programming would invoke immediately upon retrieving the record and then any time I clicked the mouse anywhere on the screen!  The only programming I had was a writeln() statement.

Not sure where to go from here....

I've got is kinda working.  I have a few lines of programming that are invoked in the ON DRAW area.  Everything seems to be working OK except when I go to TABLE view.  The screen seems to "double" (see attached; note the top of the picture). 

If I click on a tab at the bottom of the Sesame application and then come back to this one, the table is now visible!

Is my programming interfering with the table view action?  Here's the programming:


If IssueClosed ="N"
{

     RGBColor(BasicDescription, 0,0,0,255,255,255)
}
Else
{
     If IssueClosed ="Y"
     {
           RGBColor(BasicDescription, 0, 0, 0, 226,145,145)
     }
     Else
     {
           If @IsBlank(IssueClosed)
           {
                 RGBColor(IssueClosed, 0, 0, 0, 255,255,255)
           }
           
     }
}
     

Let me know what you think.

Thanks!
                 

I reduced the programming to make it as simple as possible, however the color status of BASIC DESCRIPTION depends on the value in ISSUECLOSED. 

Are you saying that the On Draw event won't work if I check a different element to determine the color status of the element of interest? 

My latest programming is:

If IssueClosed ="N"
{

     RGBColor(BasicDescription, 0,0,0,255,255,255)
}

This programming behaves the same way, that is, the screen appears to lock up, but if I activate a different tab in Sesame and then return to the tab of interest it is fine.

Any suggestions?

I don't know what "pen", "brush" and "clip region" are.  My latest programming tries to affect only one element, yet I still get the error effect. 

I guess I'll have to eliminate this programming and live with the color not being correct in table view.  No big deal.

My latest program is in the correct element's On Draw event.