window trigger needed

Is there a trigger for switching between a schematic and a layout
window and vice versa?

thanks,

Dominic DuVarney

 

Correction, I don't want a trigger for switching between the 2, I want to
run a function when I switch between a schematic and layout.

--

 

Hi Dominic,

I'm assuming you're talking about descending from a schematic into a layout?
(or returning from a layout into a schematic)? If so, you can use
deRegUserTriggers() for that. This can register a function which will get called
(either an application trigger, a menu trigger, or a post-install trigger) and
will be told what event caused it via the arguments. The same functions will get
called when you open a new window - but the information in the argument to say
what event occurred will be different.

If this is it, it's covered well in the manuals. If this isn't it, perhaps you
can explain further what you mean by "switching" from schematic to layout?

Regards,

Andrew.

 

Hi, this is a small example, based on a window popup menu,
you can place dynamic created entries in the item and callback
lists as well, should also work with fixed menus.

But I wouldn't say that is is a trigger, it just detects
what type is the current edited cellview and switches entries based on
that.

Hope this helps,
Bernd



procedure( BFraiseWindowsPopUp( )
let( ( l_itemList l_callBackList )

cond(
( geGetEditCellView()~>cellViewType == "schematic"
l_itemList = list( "Schematic" )
l_callBackList = list(
"printf( \"The application is the schematic editor\n\" )" )
)
( geGetEditCellView()~>cellViewType == "maskLayout"
l_itemList = list( "Layout" )
l_callBackList = list(
"printf( \"The application is the layout editor\n\" )" )
)
) ;; close cond

hiDisplayMenu(
hiCreateSimpleMenu(
'BFpopUpMenu
"Application"
l_itemList
l_callBackList
) ;; close hiCreateSimpleMenu
) ;; close hiDisplayMenu

) ;; close let

) ;; close BFraiseWindowsPopUp



;; building the bindkeys for all usefull applications
let( ( l_applicationList )

l_applicationList = list(
"Layout"
"Schematics"
)

foreach( t_application l_applicationList
hiSetBindKey( t_application "<Key>F8" "BFraiseWindowsPopUp( )" )
) ;; close foreach
) ;; close let

 

Thanks for the reply Bernard. Finding the application in a
function isn't my issue though. I want to trigger a function call
just by making the window with the different tool active. I want
to update my menu entries immmediately upon a tool change without
having to use a bindkey. Thanks again for taking the time to reply.

--

 

.... this is a 'window manager' task.
A SKILL trigger needs somehow an event, opening a window or launching
an application.
Honestly I think what you want do is not possible that way.

Bernd

 

Bernd is right. There's no trigger (at least at the SKILL level) that gets
invoked upon a window being current.

It writes hiSetCurrentWindow(window(num)) into the CDS.log file - but it didn't
actually call hiSetCurrentWindow - not that this would help, since you can't
intercept it - this is so that replaying of the log file works.

I did find a PCR asking for this:

PCR: 409445
Title: How to register current window change trigger ?

Which does have a workaround within it - not exactly a nice way of doing it, but
better than nothing:

MyCurWindow = 0
procedure( MyCheckCurWindowCB( )
let( (newCurWindow)
newCurWindow = hiGetCurrentWindow()
when( newCurWindow && newCurWindow != MyCurWindow
printf( "Old current window = %d, new current window = %d\n"
MyCurWindow newCurWindow )
MyCurWindow = newCurWindow
)
hiRegTimer( "MyCheckCurWindowCB()" 5 )
)
)
MyCheckCurWindowCB()

(Thanks to Pete Zakel for the workaround code).

Obviously you should minimise the amount of code that is being invoked every
half second (which is what the above does) .

Regards,

Andrew.

 

Thanks Andrew,

That's actually how I am currently doing it, but am concerned
about long term drain on system resources. The code below works
but it just seems sloppy. This is code I want let cicuit and layout
designers use but doing a repetitive check isn't something I would
feel comfortable with without knowing potential side effects.



procedure(checkVT()
when(hiGetCurrentWindow()
unless(boundp('lastVT) lastVT = "maskLayout")
unless( deGetViewType() == lastVT
lastVT = deGetEditViewType()
when(boundp('myFixedMenu) && hiIsFormDisplayed(myFixedMenu)
when(lastVT == "maskLayout" updateMyFixedMenu(?tool "layout"))
when(lastVT == "schematic" undateMyFixedMenu(?tool "schematic"))
)
)
)
hiRegTimer("checkVT()" 30)
)

Once again, thanks for your help Andrew.

--

 

Actually, hiRegCurWindowTrigger() was added in IC 5.2.51, so it will be
available in newer releases.

Until then, the workaround Andrew posted should work.

-Pete Zakel
()

There is one fault that I must find
With the twentieth century,
And I'll put it in a couple of words:
Too adventury.
What I'd like would be some nice dull monotony
If anyone's gotony.

- Ogden Nash

 

Hi Dominic,

I agree, it's inelegant. But the only option if you want the UI to work that
way...

That said, your code would be better if it recorded its own idea of the current
window, and only updated your form if the current window was different from the
recorded current window. This means it would not actually be doing much work
every time the polling occurs - unless the current window had changed (which is
presumably a relatively rare event compared with the period of the timer).

I suppose you're doing that by checking whether the view type matches the last
view type - but even deGetViewType() probably takes some resources (although not
many). Perhaps you could check first the window changing, then the view type?

Regards,

Andrew.

 

I'll be watching for it. Thanks to all who contributed to this topic.
I may just have users manually do the change until the new trigger is
available to us.

--