Is it possible to handle a Connect/Callback construction within a CTRL++ class?

[michel.eijgermans]

From the last London Userdays i thought that 3.15 CTRL++ would be capabel of handling a Connect/Callback construction within a Class. But until now i didn't succeed to get it working.

i've created a class witha the class constructor that creates the 'dpConnect()' to a given dp-element. The class should handle all events coming from the datapoint.
As a callback functionname i gave a member function of the same Class.
The member function receives two parameters .. DpElName and Value

I instantiated an object-A of the class.
What i see is that the member function of the class is called on each dp-change but it seems to be that it doesn't know the Instance (object-A) of the Class anymore, callback function lies out of scope of the object-A?!?!
Interal variables of the object-A can't be written.

I also tried a construction with the new 'function_ptr' variable type, but until without success.

My questions,
- Is it possible to handle a Connect/Callback on a DP within a class?
- If its possible, is there a small example code how to define the class and callback function and usage in code?

[flindecke]

i have found an example at CERN https://wikis.web.cern.ch/wikis/display ... OA+CTRL+OO
You need a "trampoline" function which gets the "this" object pointer. This "trampoline" functions calls a second well known "trampoline" method on the object, which finally calls your method.

[fmulder]

Please note that the Cern example also shows some warnings.
I believe that you should be very careful with code like this. WinCC OA, or scada projects in general, need to run and need to be maintained for many years. The example shown here demonstrates quite complex code that many engineers, who feel comfortable in the 'normal' scripting language, will find difficult to understand and maintain.
I do believe that the Control++ offers some interesting possibilities, but you should be careful that you do not make it too complex.

[flindecke]

I agree with Frenk!

Code complexity is introduced by the inability to call methods of objects as callbacks for dpConnect.
The "trampoline" function and method are only needed to get the desired behavior.

It would be nice to get rid of them. Perhaps in WinCC OA 3.17

[Gertjan van Schijndel]

As with other object oriented languages, without object you can only call static functions of a class.

The online help mentions this in the 'function_ptr' (CONTROL -> Introduction CONTROL -> Object Oriented Scripting (CTRL++)) part:

The new data type: function_ptr (a function pointer) can hold a pointer to some CTRL script function, e.g. to a class member function. The member function must be declared static.
Non-static functions are not possible, since the called function does not have an object (an instance of the class Base) and therefore no "this" variable.

[michel.eijgermans]

The Cern example nicely shows that complexity is disproportionally increased when you try to get callbacks inside an instanced object.
It would be nice to see it possible in the near future, if you ask me 3.15.sp1 would be a nice date .

[fmulder]

OO programming has many beautiful features and benefits that can make it easier to understand and maintain code. Some of this functionality is now also available for WinCC OA. I can imagine that we can implement beautiful helper classes for various jobs. And for sure there will be situations where a class can greatly help your scripting challenge.

Personally my preferred approach is:
1) make a library that is used in N projects
2) Project engineers should only instantiate a framework and should only draw 'floorplans' and icons. Basically, your library should be so good that an (almost) unskilled WinCC OA engineer can still implement an application (helped by an expert to implement some project specific scripting. I see no reason, for the floorplans and the icons, to use classes. The classes do not make the simple icons any easier.

The classes bring some possibilities that we could benefit from. But be aware that we already use similar functionalities:
1) a class brings code together in one logical place. E.g. a class 'XMLReader' could offer all functions to read or write XMl files.
Today we combine such functions into script libraries and give all functions a unique prefix e.g. 'xml_XXXXX'
2) A class can have virtual methods that you can override
Today we do something similar by using HOOK functions. Example:

Code: Select all

if( isFunctionDefined( "HOOK_xml_Opendocument" ))
  HOOK_xml_OpenDocument();

3) Use a class as a 'struct' to store data
We frequently love the beautiful 'mapping' datatype

But still. Will be quite interesting to look at the OO possibilities

p.s. Don't forget the OO panels which I do believe will benefit the icons quite much !!!