Hola a tothom,

I have the following issue, I'm building a new session which calls via API an standard BaaN session (tdlra0110s000). This std session is acting in different ways depending on the main session that zooms to it. What I would like to do is the following: my session zooms to tdlra0110s000 and it should "think" that the program that called it (my session) is tdmdm2120s000 instead of my session.

Does somebody know how can I cheat the session about where is zoomed from?

thanks & regards

Jordi

try these predefined variables

string
zoomfield$(18)
4R
Variable set in the zoom session, indicating which field in the parent session was zoomed from.

string
zoomreturn$(18)
4R
Variable set in the zoom session, indicating which field's value is to be returned. In the parent session, the variable attr.zoomreturn$ has the same value.

I already checked them but the problem is that they are only Read variables and I can't overwrite their value.

You can check in the called session the api.mode variable; if it is true, it means that the session is called thru a function server call (your new session).

The called session is std BaaN and I can't modify it because I don't have the source.

The only solution seems to call the API for both the main session tdmdm2120s000 and the zoomed session.

If tdlra0110s000 uses zoomfield$ = "tdmdm2120m000" for it's expected behavior , following code to zoom may help .


string test(100) , zoomreturnfield(100)
test = zoom.to$("tdlra0110s000",z.session,"tdmdm2120m000",zoomreturnfield,0)


Beware such checks in standards are to ensure consistency of data . If u r unable to grasp (through ur custom programs) or u make mistake in doing so , the onus of problem lies on u and not standard program.

The called session is std BaaN and I can't modify it because I don't have the source.

Do you have one of the wrapper programs (Q-key, RMCis, or ~Vamsi)? Using one of those methods would allow you to do some of the suggestions.

Also sometimes the sessions use a field like zoom.session - you just be able to set that and export. Can't really say since I am not familiar with your system.

Mark,

I'm not using any wrapper program. I just using AFS functionality of BaaN

Do you even have source code to look at? Sometimes you might be able to find a short cut from that. If not then I can not think of anyway to trick the system without you having to call the main session first and working through the subsessions.

Normally zoom names are session code or field code from where it is zoomed . U can view all zoom names in ttadv2439m000 exported function prototypes like zoom.from.tdmdm2120m00 . All zoom.from section in zoomed session will be executed only if zoom name is non-blank

Hello,

attached you can find the code I'm using. My program called tdmdmc910m000 uses this function which starts session tdlra0110s000 using API dll. What I want is that tdlra0110s000 act as the process that called it is tdmdm2120s000 instead of my session (tdmdmc910m000):

function extern domain tdlra.leno tdmdm.cdll800.create.idno(
domain tcitem item.in,
domain tccwar cwar.in,
domain tdmdm.dset dset.in,
domain tdlra.valu leng.in,
domain tdlra.valu widt.in,
domain tcorno qana.in,
ref domain tcbool o.stat,
ref domain tcmcs.str100 o.mess)
{
dllusage
|******************************************************************************
|* ARGUMENTS
|* item.in - Item
|* cwar.in - Warehouse
|* dset.in - Dimension Set
|* leng.in - Length
|* widt.in - Width
|* o.stat - Status of the action (output)
|* 1 - OK, 0 - Not OK
|* o.mess - Message during creation (output)
|******************************************************************************
enddllusage

domain tdlra.leno new.leno

always.yes = tcyesno.yes
always.no = tcyesno.no

cdll0110s.put.item(item.in)

cdll0110s.put.warehouse(cwar.in)

cdll0110s.put.dimension_set(dset.in)

cdll0110s.put.dim._1_value(leng.in)

cdll0110s.put.dim._2_value(widt.in)

o.stat = cdll0110s.insert(1,o.mess)

new.leno = cdll0110s.get.idno()

cdll0110s.end()



return(new.leno)
}

Yes - I understand this, but do you have source code to look at? There might be a way to trick it. But it depends on the actual code of tdlra0110s000. Some subsessions use different methods to determine the calling program - knowing what that is could be the key. I know in one case I have to set a boi variable to get the called program to act correctly. I do not know if something like this would work for you.

Not aware abt all these programs. In api.mode too, programs behave differently .Ideally u should use handle.subproc approach so that the same behavior can be expected .

if u use zoom.to$ then the functionality may work . But dont know to what extent usage zoom.to$ is feasible .