difference between asiGetSession(sevSession) and sevEnvironment(sevSession)

Laurent,

That's because asiGetSession is NOT intended to be used with sevSession symbols. What happens is that the session is not found, and it falls back to the "current" session - I think the same as asiGetCurrentSession() returns. The symbol that can be passed is the name of the asi session, which is not the same thing.

You should use sevEnvironment, not asiGetSession.

Andrew

Laurent,

That's because asiGetSession is NOT intended to be used with sevSession symbols. What happens is that the session is not found, and it falls back to the "current" session - I think the same as asiGetCurrentSession() returns. The symbol that can be passed is the name of the asi session, which is not the same thing.

You should use sevEnvironment, not asiGetSession.

Andrew

Thanks Andrew for the answer.

I can understand that asiGetSession is not intended to be used with sevSession symbols. I'm sceptical on the fact that sometimes asiGetCurrentSession returns the same object as sevEnvironment and sometilmes not...

Let me detail why I'd prefer not use sevEnvironment.

Starting from code working with ADE-L (where the argument passed to asiGetSession was the ADE-L windowId), I would like to use code in an Assembler view by using a wrapper calling the initial code. In my mind, this wrapper would collect the sevSession of a specified test and give it as argument to asiGetsession of the initial code. Apparently I was wrong!

Following your answer, I should get the asiName from the sevSession and pass it to the function asiGetSession, shouldn't I?

It woulb be in the wrapper something like :

(setq testName (getq (get form sym_testName) value))
(setq fnxSession (axlGetWindowSession (window form->maeWindowNumber)))
(setq sevSession (axlGetToolSession fnxSession testName))
(setq asiSession (sevEnvironment sevSession))
(setq asiSessionName asiSession->name)

and the initial code (that can't be modified) will run (asiGetSession argument) where argument will be asiSessionName passed from the wrapper.

Am I correct now?

Laurent.

kkdesbois said:

I'm sceptical on the fact that sometimes asiGetCurrentSession returns the same object as sevEnvironment and sometilmes not...

You can be as sceptical as you like, but that's what it does. The "current" session ends up being quite dynamic in Assembler because there are a lot of possible sessions that could be current (especially when running over sweeps and corners), but interactive use can change the current session frequently - sometimes it will end up being the same session that sevEnvironment would have returned if you have more than one test. If there's a single test then it's much more likely to be the same.

kkdesbois said:

and the initial code (that can't be modified) will run (asiGetSession argument) where argument will be asiSessionName passed from the wrapper.

It's unfortunate that your legacy code works by being passing something which can then be passed to asiGetSession (such as a window id, form id, asi name etc) rather than passing around an asi session. If that's how it is structured and you can't change it, then doing what you've proposed by getting the ->name slot from the asiSession object is the only reasonable option. I just never see anyone using that session name in practice (not sure the name slot is documented, but it's extraordinarily unlikely to change).

Personally I'd future proof the code by updating to take an asiSession as an argument instead, but it's up to you of course!

Andrew

Thank you Andrew for the deeper explanations. As you said, I guess that I faced a lucky situation where asiGetSession and sevsession returned the same object.

In short term, I'll use the trick with the ->name slot but will consider a deeper code change in the next release.

Laurent.