I have searched the archives, but cannot find specifically what I'm wanting to do.  When building a Sales Order, using subform SOLines, I want to change the ItemQty background color if the quantity is a negative number.  If the ItemQty is a positive number, then 'no background color change'.  But I need each record to retain its programmed background color in ItemQty when it switches to TableView for the PrintForm.  The color difference for negative value is to aid the delivery drivers in seeing different things on the delivery ticket, which is printed with a PrintForm command.

Is it possible to have multiple subform SOLines records on a Parent OrderForm where the ItemQty LE background color can be different on each saved record (so that each line item retains its different color, both on the screen and when printed?

What's happening with the following code is:
-ItemQty:nElementExit is changing ItemQty background to yellow if the value is negative
-this record is saved.
-Next record is created, and ItemQty background color is reset to white, FOR THE NEW RECORD, pending the subsequent value that is entered in ItemQty.  

But the background color isn't being retained differently for each record, as desired.

ItemQty:nElementChange
#Include "sbasic_include.sbas"


If @ToNumber(ItemQty) < 0
 {
   FormAttribute("", "ItemQty", ATTR_ID_BACK_RGB_COLOR, "252 252 0")
   FormAttribute("", "ItemQty", ATTR_ID_TEXT_RGB_COLOR, "252 0 0")
   ForceRedraw()
 }
so far so good, but when the next record is created, and the following code executed (to insure that ItemQty background on new record begins as white, it reverts the background colors of the previously saved records, too.

Next record, on ItemNum:nElementEntry
{
 FormAttribute("", "ItemQty", ATTR_ID_BACK_RGB_COLOR, "255 255 255")
 FormAttribute("", "ItemQty", ATTR_ID_TEXT_RGB_COLOR, "0 0 0")
 ForceRedraw()
}

Thank you, Hammer.   I'll look at it this evening.

I used the following code in ItemQty:nDraw , and Sesame didn't like it at all.  When I loaded my app and clicked on Orders from AppMenu, it showed a Search/Update Orders tab on the bottom of the Sesame screen, but wouldn't show the screen itself.  Sesame was then unresponsive to input, although the Windows task manager showed CPU utilization at 50+%, and Sesame memory cannibalization was steadily climbing from 60k to 500k.  I tried this several times, and a couple of those times (but not all of those times) I got a little message line in bottom left corner of Sesame that said compiling ItemQty (14), but then no more activity.

Going back into Sesame Designer and commenting out this piece of code fixed the stall.   What have I done wrong here?

#Include "sbasic_include.sbas"

If @FormViewType("SOLines") = FORM_VIEW_TYPE_TABLE
  {

    If @ToNumber(ItemQty) < 0
     {
       RGBColor(ItemQty, 255, 0, 0, 255, 255, 0)
     }
       else
         {
           RGBColor(ItemQty, 0, 0, 0, 255, 255, 255)
         }
  }

Ben,

I'll try to track it down.  I also had a piece of code that changed a LE background color on element entry and back again on element exit (when in Form view), that was causing runtime errors when the SOLines subform is programmatically changed to a Tableview for printing purposes.  I just commented that code out remotely and am waiting for the office to let me know if it's fixed.

OK, just heard from the office - it's fixed.  So something about changing an LE color that Tableview doesn't like, at least in my config.

Ben,

I eliminated all Orders and SOLines code that spoke of 'redrawing' (only a couple of instances existed).  The app will tolerate the first two of the following conditions in the LaunchPad element, but will not allow the Orders screen to open up if I have any code in ItemQty that speaks of changing colors (the third piece of code following), regardless of if it's OnElementChange or OnDraw:

//this piece runs fine
Launchpad::OnElementEntry
#Include "sbasic_include.sbas"

If @Mode() < 2 and @FormViewType("SOLines") = FORM_VIEW_TYPE_FORM
     {
         RGBColor(Launchpad, -1, -1, -1, 255, 255, 0)
       }

//this piece runs fine
Launchpad::OnElementExit
#Include "sbasic_include.sbas"

If @Mode() < 2 and @FormViewType("SOLines") = FORM_VIEW_TYPE_FORM
     {
         RGBColor(Launchpad, -1, -1, -1, 229, 229, 229)
       }

//this piece locks up Sesame and won't let Order screen become visible
ItemQty::OnElementChange

#Include "sbasic_include.sbas"

If @Mode() < 2 and @FormViewType("SOLines") = FORM_VIEW_TYPE_FORM
 {
   If @ToNumber(ItemQty) < 0
     {
       RGBColor(ItemQty, -1, -1, -1, 255, 255, 0)
     }
       else
         {
           RGBColor(ItemQty, -1, -1, -1, 255, 255, 255)
         }
 }

Ben,

It tests with no errors in the Program Editor.

No SBasic compilation error message.  I click on Orders in the Main Application screen, and the Search/Update Orders tab appears at the bottom of the Sesame screen, but behind the Main Application Menu screen, and there it sits, consuming 52% of the CPU and ever increasing RAM.  I have to kill it from Task Manager.

It doesn't have to be an OnDraw event.  That piece of code will have the same effect if it's an OnElementChange event.  

Question:  If there are multiple SOLines records in this set, do I have to execute a Loop through the records to determine the value of ItemQty in each record?

Update:   

Just for grins, I put the following code in an LE on the parent Orders form.  It was PickupField::OnFormEntry.   It had the same 'lockup/freeze' effect - when I clicked on the Orders Menu button from the Application Menu screen, the Search/Update Orders tab showed below, but the orders screen wouldn't become visible, and Sesame was then non-responsive to any input.  Had to kill it with Task Manager.

PickupField::OnFormEntry

#Include "sbasic_include.sbas"

If @Mode() < 2 and (@IsBlank(PickupField) = 0)
  {
    RGBColor(PickupField, -1, -1, -1, 252, 252, 0)
  }

Latest update ...

My app locked up/froze with the following commented-out code in SOLines:nDraw.  It seems that it doesn't want an OnDraw event even listed in the Program Editor (or else doesn't want the single blank space between the two commented out sections).   Once I deleted the SOLines:nDraw event, unlocked, reconciled and re-opened the app, Orders screen came up just fine.

/*
#INCLUDE "SBASIC_INCLUDE.SBAS"

If @FormViewType("SOLines") = FORM_VIEW_TYPE_TABLE
     {   
       RGBColor(ItemUoM, -1, -1, -1, 255, 255, 0)
       ForceRedraw()
     }
      else
        {
          RGBColor(ItemUoM, -1, -1, -1, 255, 255, 255)
          ForceRedraw()
        }
   
*/ 

/*

    If @ToNumber(ItemQty) < 0
     {
       RGBColor(ItemQty, -1, -1, -1, 255, 255, 0)
     }

       else
         {
           RGBColor(ItemQty, -1, -1, -1, 255, 255, 255)
         }
    ForceRedraw()
  }
*/

Hammer,

You're not the first person to reply to me with the comment "too much information".  HaHa.  I just didn't want anyone to think I was being lazy!

I'm going to send your comment to my daughter, who has rolled her eyes over 'too much information' coming from me for many years - she'll get a good laugh out of that.

Hi Ben,

will send them this afternoon.

Thank you!

Larry

Ben,  thanks!  Didn't know better, but now I do.  I'll make the changes tonight.

Larry

Try the following in your ItemQty :: On Draw event. Removing the ForceRedraw() statements will at the very least decrease some of the load time and slowdowns that you were seeing in the subform.

If @FormViewType("SOLines") = FORM_VIEW_TYPE_TABLE
     {
	 RGBColor(ItemUoM, -1, -1, -1, 255, 255, 0)
     }
	else
	  {
	    RGBColor(ItemUoM, -1, -1, -1, 255, 255, 255)
	  }

    If @ToNumber(ItemQty) < 0
     {
	 RGBColor(ItemQty, -1, -1, -1, 255, 255, 0)
     }

	 else
	   {
	     RGBColor(ItemQty, -1, -1, -1, 255, 255, 255)
	   }
 

Can you provide us some general information about your machine. General specs like the RAM, Processor, Operating System, etc.

How long do you let Sesame sit when it appears to be locked up before you tell windows to end the task?

Try letting it work for 5-10 minutes just to see if it picks back up and finishes loading.

We can also setup a GoToMeeting session if you like so that we can take a look at what it is doing on your machine. To schedule a meeting, email us at support@lantica.com with a time that will work for you (between 9AM and 5PM EST).

lksseven wrote on Jun 2^nd, 2009 at 11:39pm:

That part might not be you. Let us check it out. It may be a side effect of something we fixed in a previous version.