andy2609
10th February 2011, 15:18
Hi all

I am writing a UI script and from this I want to call a sub-session which has the function 'wait.for.switch(SWITCH.SAME.SIZE)' as the first command in its 'init.form' section.

When my new script calls the target session, it hangs (no doubt due to this function) and will not run the process - hence not allowing any interaction. I have to kill the process manually to return control to the calling script.

Does anyone know a way around this, perhaps by skipping execution of the 'init.form' section or forcing focus back to the called process?

(The target source code exists, but cannot be modified and would not compile anyway, due to missing source for associated functions.)

Any thoughts would be welcomed.

Andy

mark_h
10th February 2011, 15:50
No expert on these but the wait.for.switch is interacting with your session, so it looks like the parent session needs to switch(switch.to.process) the the child session. In this case your API session is the parent session and the subsession is the child session. I think instead of calling the subsession directly you need to call the main session. The only time I have used it is in a combined session. I would look up the help on it, but since they upgraded my desktop it no longer works.

george7a
10th February 2011, 15:58
Here is link with some information:
http://www.baanboard.com/baanboard/showthread.php?t=36550&page=5

andy2609
10th February 2011, 18:07
Thanks for the input guys. I think you could be right, Mark, about calling the parent session, rather than the child directly. I'm going to look at this - thanks again for the response.

andy2609
10th February 2011, 19:22
Hmmm, this hasn't solved my problem

I have tried calling the main session instead and, although the parent and the child processes are appear in the process list, the process still hangs. Having set AFSLOG to debug the API process, the generated logfile's last lines are:
15->get.fields
15<-Process is gone

The latter of these will have been when I killed the processes manually. Any ideas as to how I can get control of the child process?

Andy

mark_h
10th February 2011, 20:00
Notice I moved the thread to the AFS/DDC/OLE Forum since this is getting more into the code. You can try searching this forum for the sessions in question. There is a lot of code for examples. If you don't find your sessions you will need to post at least the afs code and maybe someone will see something is wrong.

andy2609
11th February 2011, 19:12
It seems that it's not going to be possible to call the sub-session with an API call in this case. Its immediate calling script is an intermediary which imports the original parent session's ID [using 'import("prog.name$", parent.prog)'] and then launches the relevant child session, dependant on this and a few other variables, using 'switch.to.process(child.pid, SWITCH.SAME.SIZE)'. Since there is no way of the script containing the API call purporting to be the actual parent, the relevant child will never be called.

I would conclude that I would need access to compile and authority to change the source code in order to make tis work with APIs. Has anyone else had similar experience in encountering sessions that are just not suitable to be run with AFS?

mark_h
11th February 2011, 20:11
In one case(I can't remember the parent session name) did something like this. The parent session determined which child session to run. Because of this I was never able to get that to work with the parent and session. So I kind of cheated - I created a new main session to specifically launch the session I wanted. Below is the code that worked for me and the stpapi code. This code is just a piece of the code to load our simulation company - basically they give the session a file and it does all the work from building subitem, ccn links, etc. to loading and generating the orders. What it took them days/weeks to do manually, now takes them hours. This has been working for 10 years or so.

Other things I have done is to launch sessions interactively like Generate PRP Orders, use qkey(source extendor you can search on it) to get sessions to function properly. Or to even go so far as to write code to update what I need to updated - for some reasons a couple of session just would not update a field on a form, so I just do direct sql updates.


declaration:
long child.id
extern domain tcmcs.str1 x
|****************************** PROGRAM SECTION ***************************
before.program:
child.id = 0

|****************************** ZOOM FROM SECTION ***************************
|****************************** FORM SECTION ***************************
|****************************** CHOICE SECTION ***************************
choice.cont.process:
on.choice:
if(child.id<>0) then
kill(child.id)
endif
child.id=activate("tpptc9110m00c")
switch.to.process(child.id)
| Cannot use zoom because tpptc9110m00c is waiting for a
| switch.to.process
execute(end.program)

choice.interrupt:
before.choice:
execute(end.program)

choice.abort.program:
before.choice:
execute(end.program)

choice.end.program:
before.choice:
kill(child.id)


The calling stpapi function:

function add.contract.requirement()
{
if(first) then
stpapi.put.field("tpptc9831m00c","x","A")
stpapi.handle.subproc("tpptc9831m00c","tpptc9110m00c","add")
stpapi.handle.subproc("tpptc9831m00c","tipgc8120m00b","add")
stpapi.continue.process( "tpptc9831m00c", errmsg)
first = false
endif

| Set the first view.
stpapi.put.field( "tpptc9110m00c", "tpptc120.cprj", project )
stpapi.put.field( "tpptc9110m00c", "tpptc120.cspa", "1000" )
e = stpapi.change.view( "tpptc9110m00c" )
stpapi.put.field( "tpptc9110m00c", "tpptc120.cprj", project )
stpapi.put.field( "tpptc9110m00c", "tpptc120.cspa", "1000" )
stpapi.put.field( "tpptc9110m00c", "tpptc120.sern", str$(msnumber*10) )
stpapi.put.field( "tpptc9110m00c", "tpptc120.cpla", "001" )
stpapi.put.field( "tpptc9110m00c", "tpptc120.cact", milestone )
stpapi.put.field( "tpptc9110m00c", "tpptc120.item", item )
stpapi.put.field( "tpptc9110m00c", "tpptc120.prog.a", program )
stpapi.put.field( "tpptc9110m00c", "tpptc120.eser.a", unit )
stpapi.put.field( "tpptc9110m00c", "tpptc120.ese1.a", str$(series) )
stpapi.put.field( "tpptc9110m00c", "tpptc120.ese2.a", str$(series) )
stpapi.put.field( "tpptc9110m00c", "tpptc120.quan", str$(msqty) )
stpapi.put.field( "tpptc9110m00c", "tpptc120.cuni", "EA" )
if current.compnr <> 101 and current.compnr<> 555 then
stpapi.put.field( "tpptc9110m00c", "tpptc120.clin.c", "" )
stpapi.put.field( "tpptc9110m00c", "tpptc120.stat", str$(tpptc.stat.free) )
else
stpapi.put.field( "tpptc9110m00c", "tpptc120.clin.c", clin )
stpapi.put.field( "tpptc9110m00c", "tpptc120.stat", str$(tpptc.stat.actual) )
endif
if current.compnr <> 101 and current.compnr<> 555 then
stpapi.put.field( "tpptc9110m00c", "tpptc120.simu.a", str$(tcyesno.yes))
else
stpapi.put.field( "tpptc9110m00c", "tpptc120.simu.a", str$(tcyesno.no))
endif
stpapi.put.field( "tpptc9110m00c", "tpptc120.ccco", "200" )
stpapi.put.field( "tpptc9110m00c", "tpptc120.dfpc", str$(tppdm.yeno.no) )
stpapi.put.field( "tpptc9110m00c", "tpptc120.butm.a", builditem )
stpapi.put.field( "tpptc9110m00c", "tpptc120.sbtm.a", subitem )
stpapi.put.field( "tpptc9110m00c", "tpptc120.dtyp.a", str$(tppss.dtyp.a.customer) )
stpapi.insert( "tpptc9110m00c", 1, errmsg )
if(strip$(errmsg)<>"") then
mess.5= "5. "&errmsg
write.error(mess.5)
stpapi.recover("tpptc9110m00c",errmsg)
if(strip$(errmsg)<>"") then
message(errmsg)
endif
else
mess.5="5. MDO Added."
endif
display("mess.5")
}

andy2609
14th February 2011, 11:36
Thanks again for the information Mark - good of you to take the time to reply in this detail. Yes, I too am coming to the conclusion that I will have to devise a workaround here, rather than being able to use AFS, due to its limitations. I am trying to deduce what updates are being done by the relevant sessions (not so easy when there is missing source). I have taken a quick look at Qkey in this forum - this looks interesting and I haven't come across it - though it looks as though it has been around for a while. Do you have any details of cost for the product? Presumably, it has to be installed on the same platform as Baan and doesn't require much maintenance?

mark_h
15th February 2011, 02:38
I can't give a price on qkey, because I am not sure it is available anymore. I also can't seem to remember who redclay sold it too, but I don't think they offer support anymore. But yes it was easy to maintain. I would probably check with Crossroads RMCis about their product. That would at least be supported.