I am trying to go from a form in add mode, and Load Retrieve Spec. My Debugging has been successful, Form loads in Search mode, however empty (without retrieve specification) and WriteLn Window states "Retrieve Spec Loaded", however, I come to find out the Retrieve Spec is loading into open form in Add Data instead of Search Form. Obviously I am not getting the Focus of the Form in the Search Mode.  

Following is the Code I am Placing in Command Button in Element Entry event.  My staring point is open form in add data mode.

var vSuccess as Int
           
     vSuccess = @SelectTreeItem ("Add Data Menu!Application Menu")
                             VSuccess = @SelectTreeItem ("NewSesameApplication!Forms!Search/Update!NewDatabase!NewForm")

     If vSuccess = 1 then
           //Writeln ("Gone into Another Tree")

           
vSuccess = @LoadRetrieveSpec ("stumps")

if vSuccess = 1 then
           Writeln ("Retrieve Spec Successfully Loaded")

Can someone pointout what am I doing wrong? I want to keep Form open in Add Mode, because I have all the intention to work on it, once I have completed looking into Retrieved Data.

Found and fixed. The fix will be in 1.0.2. The problem is that it was writing the spec to the wrong form. All you will need to do (in 1.0.2) is:

vSuccess = @LoadRetrieveSpec("r_spec_name")

and then use SelectTreeItem to kick off the retrieve. It will switch forms automagically to the retrieve form of the add/update you are on. If you need it to open an unrelated form, open the add/update mode for that form and load the retrieve from there.

I'm not exactly sure what you are trying to do, but you might consider using macros. I just recorded one that went from Add/Update mode into Retrieve mode, set the city LE to "Par.." and retrieved the two matching records (in the Customers.db).

I know I usually lean toward SBasic instead of macros, but a similar technique might get you past this problem and be an okay workaround until 1.0.2.

I agree about macros. To compensate somewhat for their shortcomings when it comes to design changes, some recorded events do not store the location of the element, but an identifier of the element (not foolproof).

Try this (for fun): go into Customers.db and record a macro that clicks on the Company LE in the retrieve form and fills in the value "Hunts". Save the macro. Go into SDesigner and switch the positions of Company and City. Save to a new .db. Go into the new .db in Sesame and go to the retrieve form, load and run the macro. It goes and finds the "Company" LE.

I believe that events involving the command tree work in a similar way - so we can add to the command tree and most macros using it should continue to work so long as the selected item is still there.

Macros will probably always take a backseat to SBasic for critical automation tasks - but they can be a lot of fun and very useful. For example, did you know that you can issue an "Exit" from the File pulldown in Sesame while recording a macro. Sesame will record that you want to exit - but won't really exit while recording - that way you can stop recording and save your macro. Then you can create a batch file (.bat file) that invokes Sesame using the -macro flag and turn Sesame into a batch processor. On each line, Sesame will be invoked, load the .db file, load and run the macro - and then exit - so the next line in the .bat file can run.

i.e.:

sesame -macro my_mac.mac db_file1.db
sesame -macro my_mac.mac db_file2.db
sesame -macro my_mac.mac db_file3.db
sesame -macro my_mac.mac db_file4.db
sesame -macro my_mac.mac db_file5.db
sesame -macro my_mac.mac db_file6.db

causing Sesame to operate on a series of .db files all using the same macro.

to add to my last post, I'm noticing that command buttons don't execute when in Search/Update mode, only when in Add Mode or after a search is performed.
that makes for rather an inconvenience, no?