• 首页
• HFSS教程
• ADS教程
• CST教程
• 射频工程师培训
• 微波仪器操作培训
• 天线设计培训
• 射频专业基础课

Ansoft Designer / Ansys Designer 在线帮助文档：

The Designer Desktop >
Desktop Windows and Features >
   Message Manager >
       Creating a Message Action           

Creating a Message Action

To configure a message action:

1. Create a message (AnsoftMessage or DesktopMessage) with desired type and action parameters. The type and action parameters should be set so that they can be used later to determine the action for the given message. (See 4b.) The boolean argument which indicates that the message has an action should be set to True.

a. There are two available AString action parameters on AnsoftMessage and DesktopMessage constructors.

b. MessageElementType has been typedefed to an int so that new types may be added without changing the existing enum in MessageManagerDefs.h. Type numbers need only to be unique within each action request receiver (see 2).

2. The message must be given a context before being added to the message window. The context is used to determine where the request for message action is to be sent. The request for message action will be sent to either the corresponding IProject, IEditor, IDesignEditorInstance, or IDesktop.

3. The class that will receive the message action request needs to derive from the interface class, IMessageActionHandler.

4. There are two methods to implement in this class.

a. Define the GetIMessageActionHandler() virtual method (from IProject, IEditor, IDesignEditorInstance or IDesktop).

virtual IMessageActionHandler* GetIMessageActionHandler();

b. Define the IMessageActionHandler virtual method to perform the message action using the type and parameters added to the message when it was created.

virtual bool DoAction(AnsoftMessage* msg);

Care must be taken that messages are cleared from the message window when a message action request receiver object is deleted. This avoids problems due to attempting a message action when the underlying receiver is gone. There are places/situations where this is already being handled.

1. DeskTopApp::CloseProject() - clears messages for a project when it is closed

2. DesignInstanceBase::OnDeleteInstance() - clears messages for a design instance when removed from the project

3. CDesktopDoc::RemoveDefinitionEditor() - clears messages for a definition editor when it is removed. This supports clearing messages for the symbol editor, footprint editor, and Designer C Model editor.

4. CSimEditView::ViewBeingDestroyed() - clears messages for the netlist and script definitions editors. These definition editors do not go away when the view is closed (as the symbol editor etc do). The data for the netlist and script editors is reset each time that a first window is opened on an editor. Even if the editor is still around, existing messages can't rely on it to have appropriate information after its last view is destroyed. So, the messages are cleared when the last view is destroyed.

5. Layout, schematic, and netlist design editors do not go away when the view is closed, but their data is not reset when a window is opened again. If the editor is around, it still has appropriate information. So, the messages for these editors do not need to be cleared when the view is destroyed. The editors go away when the design goes away. So, clearing design messages in DesignInstanceBase::OnDeleteInstance handles these editor messages.

There may be additional message action request receivers that need to have messages cleared. These can be supported by creating an AnsoftCommandContext that matches the one used to create messages for this receiver and passing it into IMessageWindow::ClearMessages(). This call should be made when the message action request receiver is being removed from use.

Examples of Supporting a Message Action

CDynamicNportDataObject::InterpolateSolution() creates a message with the type ICircuitInstance::kDefinitionMessage. actionParam1 is filled with <library type>;<definition comboName>. The AnsoftMessage information is given a context later, in PostMessagesToWindow() which is in the file NetlistCosimFunctions.cpp. The project and design editor instance are specified. The request for action for this message will be sent to the corresponding IDesignEditorInstance. CircuitInstance is that IDesignEditorInstance. IMessageActionHandler has been added as an interface to CircuitInstance so that it can be the action request receiver. CircuitInstance::DoAction() is defined to use the actionParam1 of kDefinitionMessage messages to be open the associated definition editor.

CircuitInstance is also the action request receiver for messages of type kCompInstanceMessage. Messages of this type have actionParam1 contain compinst id(s) separated by ";". actionParam2 is empty if the compinst(s) are at this level of hierarchy. If the compinst(s) are at another level, actionParam2 contains the "path" (compinst ids separated by ";") to the level of the actionParam1 compinst(s). The two parameters are used to select the compinst(s) by calling Circuit::SelectElement(). The messages being set to trigger this action are coming from the Nexxim engine. Rather than change the engine code, the existing messages are being parsed and the action information added to them. This is being done when the context is added to the messages in CAltraProgressInterface::PostAnsoftMessage().

                HFSS视频教程                                      ADS视频教程                               CST视频教程                           Ansoft Designer 中文教程

      Copyright © 2006 - 2013   微波EDA网, All Rights Reserved    业务联系：mweda@163.com