is virtuoso can create unique runtime space for each cxt

Ok, 6 days past, it seems that there is not exist method to reach it.

Hi James²,

I am not sure to understand your question.

If you want every Gui to have their own context, use the let() function to restrict every variable locally to the call of your app.

Or do you want to have acces to a common name variable to all your app' ?

In this case, a unique variable name can be used for every process i assume.

JamesJames said:

Ok, 6 days past, it seems that there is not exist method to reach it.

If this was urgent, you should have contacted customer support (using the Case menu to submit a case). Even those of us from Cadence on these forums answer in our free time - and I have been away or busy with the day job over the last few weeks.

Anyway, whilst SKILL does have a namespace mechanism, I don't think it really helps in this case (in fact it's debatable whether the namespace mechanism is useful anyway - I've posted about this in the past - it doesn't quite solve the problems you might hope it would). There are absolutely things you can do to avoid global variables, but you have to design that in - automatic retrofitting is not really something that can be done.

Andrew


let me explain:

1. my app launched by user from layout editor in a virtuoso session, and at the very begining of developing it, we use a lot of golbal variables and absolute path (formSymbol~>field~>attribute) to mainpluate the GUI and defined behavior, so, there is a restriction, we let user launch one app in one virtuoso session only for easy to implment it, which means if customer want to use my app in another layout, they must close my app first, then launch it from another layout edit window.

2. now, customer wants to use my app multiples in one virtuoso seesion. I've did some investiagtion that I think it's really tough to reach it, not only for global varibales, absolute gui path but also need to find a way to reorginize the data, and bind the my main app form to layout window, and bind the sub forms to app main forms. it's really a big tough task and very much time consumption.

3. so I want to ask if there is a simple way to reach goal ? if there is anything not clear, please ask.

Thanks

James.

James,

I did spend a fair bit of time today trying to see whether I could convince SKILL's namespace mechanism to do wha you want. I got as far as getting (say) two forms appearing from the common code, each maintaining their own state if they are launched one at a time and with the namespace active only when that form is displayed. However, if both are displayed at the same time they misbehave - something in the UI code is not playing nicely with this (as I said, the namespace mechanism is quite painful to use).

I will check with the R&D team as to why this is going wrong, but I don't have high hopes of this working correctly (well, not without a software fix).

That means you almost certainly need to design in the support for multiple invocations of the form each maintaining separate state and interacting with their own "global" data. That's not something you can magically get forms to do unless you design them to behave that way.

Andrew

Thanks for your clarificatiuon,Andrew Beckett

I'm aware that there is no simple way to get to my goal.

if it's possible please share the R&D's reply.

JamesJames said:

if it's possible please share the R&D's reply

Of course, happy to do that once I get something back (it probably needs some investigation so it may have to wait a bit because of other priorities).

Andrew