Optimizing Cimplicity 2022: Overcoming Challenges with Graphics and Embedded Classes

I am uncertain if there is a more efficient method, but this is the process I have followed. While it would be ideal if the built-in method functioned correctly, here is what I implemented. I altered my OPC address using {$OBJECT} instead of {$ADDRESS}, then directly adding the composite member name at the end. This approach functions both independently and when integrated. On the graphics aspect, I omitted the $ADDRESS parameter and solely utilized $OBJECT. I established the $OBJECT public variables on the primary screen/object as typically instructed. In standalone graphics instances, Cimplicity automatically allocated the value. However, in embedded scenarios, I executed an OPEN SCREEN event to allocate the $OBJECT variable of the object on the screen. This process was somewhat complex, requiring the use of obsolete functions as the newer functions did not seem to allow access easily (referencing the weak online help documentation). By utilizing CimObject's and cimGetScriptOwner(), I accessed the GetObject() function to select it by name. To execute this successfully, comprehensive knowledge of the object hierarchy on the screen is necessary, with all objects appropriately named (found under General -> Name). When dealing with grouped items, the process involves first obtaining the group object by name and subsequently acquiring the desired object within that group (also by name). For instance, if I have a group named Parameters containing P1, P2, P3, etc., within the script running on the main screen, the code would resemble the following: ```vb Dim oObject As GefObjectVariable Dim cObject As CimObject Set oObject = CimGetObject.GetVariable("$OBJECT") 'Automatically assigned variable by Cimplicity Set cObject = CimGetScriptOwner() 'Alternatively, could be CimGetRootObject() cObject.GetObject("Parameters").GetObject("P1").GetVariable("$OBJECT").Value = oObject.Value ``` It is unclear if this is the intended method, but this is the sole way I have discovered to effectively execute this task. This process is meticulous and requires careful attention to detail. For those seeking assistance, refer to the General tab of the object and locate the name. For grouped objects, utilize the Group tab to navigate the object hierarchy. Experienced Cimplicity programmers, please share your insight to either validate this approach or suggest a more efficient method.

• 22-10-2024
• nicherbert

Are you looking to utilize a class object with graphics in your project? Start by creating a screen file to house the graphic object and assign a variable such as "$Object" with the option of making it "Public" and giving it a generic name like "Tank". Remember to save your work. Then, input the screen file path and name in the class's general tab under Graphics file. Generate a class object based on this class. In another screen, go to the drawing menu and insert the class object. Choose the specific class object you want to display. The graphic will appear on the screen with the "$Object" variable automatically linked to the object's ID. From now on, manipulate the "$Object" variable instead of the object's name. If you have various graphics for similar objects, you can store them in the same screen file. Once you add a class object, simply right-click on the graphic to select from different optional graphics available, such as TankType1 or TankType2.

• 23-10-2024
• JunQ

JunQ recommended creating a screen file to assign a graphic object to a class object. By defining a general variable like "$Object" and specifying the object type (e.g. "Tank" under the "Public" setting), the graphic can be easily displayed on the screen. In the class tab, the file path and name must be filled out to link the graphic file. When dealing with nested class objects, the "$OBJECT" variable may encounter issues, particularly when used in the class object definition. The variable may not just represent the object instance ID, but also the composite member name (e.g. Tank1.Valve1). This can complicate tasks such as building OPC addresses or tag names. To address this issue, one workaround is to define the object using the reserved word $ADDRESS instead of $OBJECT. This method works smoothly for composite members, but may require a script for standalone objects with graphics. Cimplicity's limitation on multiple replacement steps can make it challenging to update the path correctly. In summary, dealing with nested class objects and composite members can present challenges in managing variables such as $OBJECT and $ADDRESS. Careful consideration and potential scripting may be needed to navigate these complexities effectively.

• 24-10-2024
• nicherbert

In order to pass a variable value from a group level to its child with the same variable, scripting appears to be the only solution. This can be accomplished within Cimedit by using a smart object event for permanent assignment, or in Cimview during the opening screen or other events. Below is a code snippet for reference, utilizing the "item" property to iterate through child objects without worrying about their names: ``` Option Compare Text Option CStrings On Sub OnScreenOpen() On Error GoTo errMsg Dim grpObj As GefObject Set grpObj = CimGetScreen.Object.Objects.Item("Parameters") For i = 0 To grpObj.Objects.count-1 Set objVar = CimGetObject.Objects.Item(i).GetVariable("$Object") If IsNull(objVar) Then GoTo Skip Else grpObj.Objects.Item(i).GetVariable("$Object").Value = grpObj.GetVariable("$Object").Value End If Skip: Next GoTo Done errMsg: MsgBox "Line: " & Erl & "\n" & Error(Err) Err = -1 Done: CimGetScreen.refresh false End Sub ``` This script effectively transfers variable values within a group hierarchy, ensuring seamless communication between parent and child objects.

• 25-10-2024
• JunQ

Hi there! It's great to see another Cimplicity user working through such complex tasks. Understanding and managing Composite Members within the Classes/Objects can indeed be a challenge, especially when you're juggling various variables like $ADDRESS, $OBJECT, and $ID. From what I gather from your detailed post, your usage of $ADDRESS within the object's parameter definition seems on point and should ideally help in streamlining the OPC address building process. When it comes to your graphics issue, I'd advise revisiting the settings for each Class template you're trying to incorporate. I faced a similar issue previously, and in my case, I had actually overlooked a setting within my composite member definitions, which caused those graphic hitches. Also, beyond the official documentation, don't hesitate to leverage online communities (like this one!) for specialized troubleshooting, and to shed light on the nuances of Cimplicity. Your current work, though challenging, will help the rest of us faced with similar obstacles. Keep experimenting, and keep sharing your experiences here!

• 03-01-2025
• Rebecca Hall

Welcome to the forum! It's indeed a tricky situation you've found yourself in. I've used Cimplicity extensively, and I can tell you that dealing with composite members in Classes can be quite a challenge. From my experience, $OBJECT and $ID usually work fine, but as you rightly mentioned, with composite members, it doesn't always play out as expected. A possible workaround might be creating different classes for your composite members and addressing them individually. As for graphics and templates, consider breaking down your complex templates into smaller, more manageable ones if feasible. Unfortunately, sometimes achieving the perfect solution means making compromises. I hope this helps!

• 03-01-2025
• Jane Smith