:confused:
Ok did quite some AFS programming and I know support on specific tooling is hard to get. But when the 4GL is pulling tricks, I am a bit lost.

So I drop a line here - maybe someone sees the light?

Please take a look at this debug screen and comment...

How come the error "Session has no synchronized dialog" pops up? How to solve this? How to troubleshoot? Why does the 4GL not see the synchronized dialog?

Please take a look at the function stack - is it because it starts in the abort.program where I create new transactions and updates?

Any hints are welcome.:D

My next step would be examine the outcome of Lp in the debugger... see if any variable may cause the issue.

BTW: reproduction with a bare 3GL program fails, there the synchronized dialog is started as it should. Same system.

Hi,

Did you tried using stpapi.handle.sub.proc() ?

Also, did you try variations like "Modify" instead of "modify"?

Will it be possible to post your complete AFS? May be someone can try it out. AFS has always been more of a trial and error thing. If on LN, and you are looking to do record insertions, try DAL.

Syntax is right I guess, see debug screen in my original post.:o

The work around is handle sub prog, but it yields an ugly response when the update is done.

Hi,

Doesn't seem to have any problems at my end as well (both 4GL and 3GL works fine) But again, any specific reasons for not using DAL? I can see you are try to add a record and DAL might just do the needful with less complications.

My point is: why does 4GL go wrong?
Wrong start? Choice.abort.program...
Wrong variable?
How do I avoid?

It could be as simple as a library or session code that is causing the issue. You can always pull the 4gl code out for this session and try it without anything else in the session. Maybe just a simple, find start and update. If it works it could be something in the session you trying to add it to.

Did you try to "reset" it using set.synchronized.dialog?

Did you try to "reset" it using set.synchronized.dialog?I figured that when I run that command in my 4GL session (cccustomme00) which calls the "target" session (standard) tccom4500m000 and its synchronized child (standard) tccom4100s000, the function set.synchronized.dialog would add the tccom4100s000 as a synchronized child to cccustomme00 instead of confirm tccom4100s000 is a child of tccom4500m000.

What I did try (to no avail) is to copy the tccom4500m000 to our own layer and set tccom4100s000 as its child (but set.synchronized.dialog is called according to the object information of otccom4500).

It could be as simple as a library or session code that is causing the issue. You can always pull the 4gl code out for this session and try it without anything else in the session. Maybe just a simple, find start and update. If it works it could be something in the session you trying to add it to.Yeah, the 3GL script I used for reproduction would be the start, but there the problem did not occur. Then I would be either adding complexity to that script or strip the original problematic script. Both routes will be time costly.

I tried to copy the problematic line and even retyped the line to be sure no odd characters are used...

I would prefer to "debug" the whole thing and see if I can follow the function tree where things go wrong using the -dbgfun logging from the bshell.

There is a work around in place now, but users have to ignore an ugly bshell message like:1 : process % - Fatal error : [MR_NULL_POINTER] Use of NULL pointer on ''
2 : process % - Fatal error : Can not continue in tccom4500m000 in DLL: ottstpstandard (fld.getvalue)[last function:form.control]

Good luck on debugging it. Right off hand I do not see what might cause it. I know I do have one that does some invoice matching that generates a bshell message I cannot get rid of(4gl and no way to test only the subsession that generates the error). It works, but the tester gets the bshell message that pops up for each transaction. The good thing is if it goes into production we will be using it in batch.

... I know I do have one that does some invoice matching that generates a bshell message I cannot get rid of (4gl and no way to test only the subsession that generates the error).Which message?It works,So does my work around - just add the child to the main session and "synchronizing" it using a FIND and MARK action, then UPDATE the child (and then the parent yells the inadequate message quoted before ^ but the tester gets the bshell message that pops up for each transaction.Same here. It is only when the data has to be correctedThe good thing is if it goes into production we will be using it in batch.:rolleyes: Also a solution :-D

The error I get is(the xxx is the process number from each run):
1 : process xxx - Fatal error : Link on stack failed zero pointer pushed.
2 : process xxx - Can not continue in tpppc2111m000 in dll: ottstpstandard (fill.status.field)[link.on.stack]

I tried several thinks to get around getting the bw message, but none of them worked. I think one time I took the field off the form and the error just moved to another field.

The error I get is(the xxx is the process number from each run):
1 : process xxx - Fatal error : Link on stack failed zero pointer pushed.
Similar to mine "[MR_NULL_POINTER] Use of NULL pointer on", but I did not get a clue on what the NULL pointer is used. It is not telling that.2 : process xxx - Can not continue in tpppc2111m000 in dll: ottstpstandard (fill.status.field)[link.on.stack] Here you see the session code is the main session and not the sub session? In my case it is the main session...

Actually tpppc2111m000 is a subsession called from a main session tpppc2811m000. It is one of those sessions depending on what you pick on the menu it then switches to a different session(all them are subsession but have m000 in the session name).

Ow yes this was the complex tp situation with the non standard way in Baan IV...