Why JavaScript can't find onOpen() EW method?

Question

Hello,

Please, could you give me some hint about why my WebGL app demo can't find EW onOpen() method when I run the HTML code in a web browser? Web browser thows the error "self.onOpen is not a function".

But in my DeviceClass "this" is assigned to self. Which is de device object... 

My DeviceClass is declared like this:

 

And the issue in the web browser is: 

Thank you.

Answer 1

Hello jgomez,

I suppose, what you observe is caused by Obfuscation.

During code generation most of project members are renamed to occupy less space in the JavaScript code, and on the other side to make the reverse analysis of your project a little bit more difficult. The obfuscation affects all members used inside your project and involved due to inter-member dependencies. With the attribute Generator set true you enforce the affected member to be generated regardless of its usage inside the project. In such case Embedded Wizard assumes the member is intended to be accessed from the outside of the project - for example, from the native code. The renaming of the affected member is avoided in this case.

Try following: in your project, select the method onOpen. In Inspector look for its attribute Generator. Change the attribute to the value true.

Please see also the section Invoke GUI application code from device. Note the usage of the _RequestUpdate() method to trigger EW related updates after an external event has been processed.

I hope it helps you further.

Best regards

Paul Banach

 

 

 

Comments

Hello Paul,

I tried to set Generator to "true" but nothing changed. Web browser is not able to locate "onOpen()" method from my EW DeviceInterface class.

I can see the "onOpen" function declared in the JavaScript file "Application.js" (without obfuscation) but web browser can't find it. Maybe obfuscation affects some prototype in a higher level that I can't understand?

This is an little issue for me because I can't call any EW function from the generated web.

Please could you help me?

Best Regards.

---

Hello jgomez,

could you provide us a small example project demonstrating the issue?

Best regards

Paul Banach

---

Hi Paul,

thanks for your tips, my issue is solved! I will explain what I did in case it helps anyone else.

I my project I have a "DeviceClassMachine" to declare methods and properties of my underlying machine and I use this class when I generate code for a "Linux" profile application. But I in the same project I need to generate code for a "WebGL" profile application too, so in this case I added a variant "DeviceClassMachine1" of the base class. Finally depending on what profile I need to generate only one or another is used for code generation depending on profile "Web" or "Linux".+

My mistake was that I only declared onOpen() method in the variant class for "Web" and then generated javascript doesn't found the method. To solve the issue I had to declare and empty "onOpen()" method in the base "DeviceClassMachine" for the "Linux" profile and override it in the variant class to add the functionality to the method.

I thought that variant class inherited the base class methods and could add new methods but it seems that same methods should be delcared and overrided in both classes. Once I "duplicate" and override all the methods in the base / variant classes the issue was solved:

Base class:

Variant class:

I am sorry for the explanation I don't understand exactly why this solved my issue but it did. If someone could clarify the reason that would be great.

Thank you for your time and apologies for my vague explanation.

Best Regards.

---

Hello jgomez,

Good to hear that you solved the problem. In fact, variants are not able to enhance the original class. Trying to do that would result in an ambiguous interface of the class. For example:

- Let's assume there is a class A.

- Let's assume there is variant V overriding class A.

- The variant V implements a method Foo()

- The variant V can be activated at the runtime depending on styles or at compilation time depending on profiles.

- Depending of whether the variant V is active or not, the method Foo() would be available or even not.

- This would result in the class A changing its interface dynamically.

Such dynamic behavior is not supported. The interface of a class has to be immutable. You can also compare it with classic inheritance. When you have a class A and class B descending from class A, methods added to class B are not visible in class A.

Your approach to solve the issue was correct. You ensured that the original class implements the complete interface, even if the methods are empty. Then in descending variants, you are free to implement the methods. If the variant is active, the implementation is used automatically. If the variant is not active, the default implementation found in the original class is used.

I hope the behavior is now better understandable ...

Best regards

Paul

---

Hi Pail,

yes now it is much more clear!

Thank you.