Hi all,

I've created a simple session which accepts a few inputs, performs a calculation, and displays the result in a form field. This session runs OK when called normally/manually.

There's another simple session which attempts to call the first via AFS, fill the input fields via stpapi.put.field with appropriate values, execute the "calculate" button and retrieve the calculated result via stpapi.get.field.

All appears to run smoothly with no errors, but the return value via AFS is always empty. What am I missing?

Here's the code from the calling session (agrees perfectly with that generated by ttstpcreatdll):
function call.afs.test()
{

string proj.num(9), part.num(38), err.msg(30), conv.fac(30)
domain tccuni base.unit, main.unit


proj.num = string.set$(" ", 9)
part.num(1) = "XXXyyy-1"
base.unit(1) = "m"
main.unit(1) = "kg"

stpapi.clear("tcibd0203mt01")
stpapi.put.field("tcibd0203mt01", "item.f.segment.1", proj.num)
stpapi.put.field("tcibd0203mt01", "item.f.segment.2", part.num)

stpapi.put.field("tcibd0203mt01", "basu.f", base.unit)
stpapi.put.field("tcibd0203mt01", "unit.f", main.unit)

stpapi.form.command("tcibd0203mt01", 5, "exec.cont.process", err.msg)
message(sprintf$("Error = %30s", err.msg))

stpapi.get.field("tcibd0203mt01", "main.conv.factor", conv.fac)
stpapi.get.error( )
stpapi.end.session("tcibd0203mt01")

message(sprintf$("Conversion factor = %30s", conv.fac))

}


Once I've got this running, the code will serve as a template for using AFS with an external high-level language.

HYCH,
R

I do not know anything about this session, but when is the field set when running manually? It maybe that the session works in AFS mode, but the event which displays this field may be getting skipped. If you have source you may want to put the session in debug mode and see what is happening both manually and when running from the AFS. I know in some cases I just go and check the tables directly to make sure things worked or to just get a value - rather than using the get.field functionality.

Mark

Well, both sessions are home-brew for test purposes only - the first simply does a call to a Baan DLL which calculates a conversion factor based on different manual inputs, while the second steers the first via AFS. No table fields or updates at all.

I've played around with both scripts, had them both together in debug mode and, although the first script does all that it should do, writing the calculated result in a form field, the second (via stpapi.get.field) simply cannot read the calculated field - stpapi.get.field returns an empty string. Worse, it can't read any of the form fields.

I suspect that AFS needs to have some kind of table-movement (find, update, whatever) in order for the form-fields to be accessible to AFS. Whatever; I've simply got the first session to write the calculated result to a text-file. Don't knock it - it works!

R

I do not think this is true.
I suspect that AFS needs to have some kind of table-movement (find, update, whatever) in order for the form-fields to be accessible to AFS.

There are too many functions servers that I have developed that, when testing, I do a put and then immediately follow it with get to test that the value is correct. No database action. I also use the get field to retrieve serial numbers and other fields. I am glad you have it working, but I think we are missing something else in that called session. Just do not have a clue as to what.

Mark

Mark - thanks for the input, I'll do some more testing when I get a little time to spare.

I'll just add my findings - I am not sure if I disagree with Mark or we just have found different things along the way. When debugging the program the AFS is working on, I have found it does the following:

1st Put: It will open the session, execute the before.program, other entry sections. It does NOT execute the field sections of the field I just put.
2nd, 3rd, etc: These do not execute field sections, no talking to the program script seems to occur.
Issue a Find, a Mark, a Browse, any other 'button' command, not necessarily a database command - then the field actions start happening, in accordance to what mode you are in. So, you 'set up' a find, then when you issue the find it will go through all the field sections in 'find' mode. When you do an update, it goes through those fields in an 'update mode'. So, it has to know what mode it's going to be in before it goes through the field sections. Otherwise, how would it handle such things as 'if update then'...

This is something I have dug into pretty deeply, but not for some time now, maybe things have changed. Mark, do you have a sample where you can do a 'put' then an immediate 'get' that proves the 'put' field sections have been executed? Which serial numbers are you referring to? I would be interested in putting this question to rest one way or another.

I think we are on the same page, but maybe not saying it the same. I am attaching two snapshots. One is the defaults for my session tisfc0408m000 and one where I put the project group and immediately get it. So no field sections are executed. I would expect that Robert could do the same thing, but according to his post he could not get any of the fields on his form. I would expect that on his session he could get the main.conv.factor field only AFTER the continue and if it is filled correctly. Also he should be able to do a put on one of the range fields, then do a get to see the value.

I think we mean the same thing - I do not think you have to execute an event to get form fields on the session, except when that form field is filled by an event such as insert. So a session event or field event are not necessary to get form fields. So I think we are saying the same thing. Hopefully the attachments shows what I mean.

Mark

Oops I should have been more clear on the serial number fields - yes I use get.field to retrieve that values, but only after a session event of update/insert. So - since I do not own source for most of my sessions I use get.fields to debug what may be happening where - before puts, after puts, before and after session events.

Did I say it better?? I really think we agree and maybe I just did not say it correctly.


Mark

Yep, at least, I see nothing here that I disagree with :). I have not tried to do a 'get' on the same field I just 'put', but you are right, you would not have to execute field conditions to get that, so I don't think we are conflicting.

Thx for the clarification.

Hi all,

I guess the variable conv.fact must be declared as extern because you transfer variables between processes. As you know all form fields have to be external variables. Table fields are declared as external vars by default with the table statement.

hth

Good luck

Carsten