I have to either restart Sesame Server, or recover from a backup when this program fires in Preview mode.
(This is in MFGR On Element Change. Crash occurs when I exit MFGR LE)

var vduped as string
var vstring as string
var vcollections as string
var vcollection as string

//writeln("MFGR On ELEMENT CHANGE now firing. Now populating Collection box.")

if @mode() = 2 and mfgr <> "" then
{
vcollections = @XLookUpAll(@FN, mfgr, "mfgr", "collection")
vduped = @sortstringarray(vcollections, 0)

while @len(vduped)>0
{
if @instr(vduped, ";")>0 then vstring=split(vduped, ";") else vstring = split(vduped, @newline())
if @instr(vcollection, vstring)<1 then vcollection = vcollection + vstring + ";"
vstring = ""
}
populatelistelement(collection, vcollection)
}



Seems like I need a way to only run the program if NOT in Preview mode. It works fine in runtime.

Sorry for all the trouble, but auto populating a combo box is turning out to be a fantastic feature! Next best thing to sliced bread.

Steve

We'll look at preventing an actual crash in Preview here also.

There are only two kinds of code that will run in a Retrieve Spec.
1. Code placed in On Retrieve Spec Open events
2. Code in the OnElementEntry event of a command button

As far as I can see, combo boxes are working correctly. If you were on a Retrieve Spec, you would have seen the symptoms you describe, where the code would run from a command button, but nowhere else. I didn't realize that you were on a Retrieve Spec. I saw the @Mode condition, but it didn't click that you were on a Retrieve Spec.

Quote:


It's in the Supplement in the section that talks about the new On Retrieve Spec Open event. Page 8.

Erika,

The Combo Boxes need major Help!

I've been working with the new "Deadly" stringarray commands on the combo box's almost the entire day trying to allow a user to "drill down" to a specific selection across 4 combo boxes. Making each box auto-populate using xlookups based on the users previous selection.

While I finally got it to do what I wanted, I've crashed sesame probably 50 times or more and permanently damaged a whole slew of working databases. Thank goodness for backups.

I've learned a few things that I thought i should share about combo boxes.

Most of my testing was done in Search mode and each box begins with:

if @mode=2 and box1 <> "" then...

On Element Change is firing during "On element exit" (without making a change) AND "On retrieve spec open". While in Update mode, Pressing f7 to go into search mode, the screen clears, thus firing the combo boxes. Putting @askuser in the On element change causes the mode change to pause. (in my case, xlookups were firing, and possibly colliding.)

Also, pressing f3 in search mode to clear all fields is firing each box. I got around this by adding If box1 <> "" after the @mode=2 condition.

Also, pressing F10 while the cursor is sitting in a box will also cause the box to fire. This is also causing unexpected results and crashes.

I beleive that if you try to run most/all of the new string array commands on a string that does not exist, Sesame will crash. (It should return 0?) Especially Populatelistelement.

After doing a search and returning no results, the On element change fires with each "On entry" and "On exit" event while in search mode. (Then sesame crashes while trying to exit)

I pasted a program from one of the boxes below. The system seems to work great, MOST OF THE TIME. I think the error may occur when no results are found.

Do you have any suggestions?

Thanks
Steve

var vduped as string
var vstring as string
var x as int =1
var vcollection as string
var vstripped as string
var vlist as string
var vfindcounter as int = 0
var vpatterns as string
var vpattern as string
var vdump as string
var vfind as int = 1

if @mode() = 2 and collection <> "" then
{

if @askuser("Collections wants to fire. OK?","","")
{
if mfgr <> "" and collection <> ""
{
vmasterlist= @xlookupsourcelistall(@fn, mfgr, "admin!mfgr", "collection;pattern;color")
if vmasterlist <> ""
{
//writeln("1 vmasterlist = " + vmasterlist)
vlist = @replace(vmasterlist, ";", "|")         
//writeln("2 vlist = " + vlist)
vlist = @replace(vlist, @newline(), ";")
//writeln("3 vlist = " + vlist)
vstripped = @containsstringarray(vlist, collection, 1)  ///build string of ALL matching collections tied to patterns and colors
//writeln("4 vstripped = " + vstripped + @newline())
vstripped = @replace(vstripped, collection, "+")
//writeln("5 vstripped = " + vstripped + @newline())
vstripped = @replace(vstripped, "+|", "")
//writeln("6 vstripped = " + vstripped + @newline())
while @instr(vstripped, "|")>0
{
vpatterns = vpatterns +split(vstripped, "|") + ";"
vdump = split(vstripped, ";")
}
//writeln("7 vpatterns = " + vpatterns + @newline())
if vpatterns <> "" then vduped = @sortstringarray(vpatterns, 0)       //alphebetize the list

//writeln("Vduped list of Patterns = "+vduped)
//vpattern = "test2;test1;"
while @len(vduped)>0                        // strip out the dupes
{
if @instr(vduped, ";")>0 then vstring=split(vduped, ";") else vstring = split(vduped, @newline())
vfind=@findstringarray(vpattern, vstring)
if vfind <1 then vpattern = vpattern + vstring + ";"
//writeln("Final results for combo box :" + vpattern)
vstring = ""
}

if vpattern <> "" then
{
clear(pattern, color)
populatelistelement(pattern, vpattern)      //put the list into the Pattern combo box
populatelistelement(color, "")
}
//writeln("now populate with : "+vpattern)
}
} //end if xlookupsourcelist failed
} //end if not in search mode
}

Steve,

We've been trying to create your failure conditions, but have not been able to do so. The String Array functions we've tried and looked at are prepared to handle blank values, so we don't think that that is, in itself, the problem. Could you send in your app along with some instructions for how to replicate the problem so we can put it in the debugger and see what you are seeing?

Thanks!

Steve,

The client crashing does not necessarily take down the Server. The Server may still be running happily with your app still loaded. Sunlocking a validly loaded app is a bad thing to do. You may have simply been able to reconnect a Client and keep working. I suspect that you may, somewhere in all the saving of new apps and sunlocking, forced an overwrite of loaded application files. This would cause much badness.

I don't think your code itself is eating your apps, which I'm quite happy about!

I think your right. I did something to a loaded app that caused a problem.

i thought that an "open ap" was an ap that was in use by a client.  I knew no clients were open, so I thought this was a bad thing and tried to restart or unlock it.

But heres why:

I just crashed twice so I could give you the error messages. The server is still running 'happily', BUT is showing :
Open Applications:
System Database
RugStudio
Rugstudio

This is why I would restart the server. It should not show Rugstudio at all, right? (No clients are open becuase they crashed.