Two properties to communicate with each other with two different classes

Question

Hi,

I am stuck with the property in two different classes not communicating. I am trying to display the value on the ValueDisplay1 but am having a really hard time. Please help.
 

In depth explanation would help.

Thank you!

Answer 1

Hello,

to help you, please explain the problem more in detail.

Best regards

Paul Banach

Comments

Paul, 

Thanks for your reply. I will try to be as brief as possible. 

The first two images which can be seen above are the Autoobject and their properties and variables. This auto object seems to be working fine but I have another issue which will be seen shortly. 

When I start the Applicaiton::Start page it automatically triggers the Nozzle_Temp Slot when there is nothing that is triggering it. No Timer or any other widget triggers it but it gets triggered somehow. It's a mystery to me. 

Now let's say, I click on the Volume of Part to activate a new screen to input my Volume, It saves the values for T (temperature) and N (number of parts) before moving on. At this point, the values should be saved as Strings.

Now the new screen comes on as expected. Which is just as I intended. 

After inputting the desired value, when enter is clicked, it saves the value as the autoobject variable. 

But for some reason, it either does not or loses them during page change.

  

It does not save the values/strings What should I do? Any advice, tips, or tricks would help. I have tried using both properties and variables. 

Thanks! 

 

---

Hello,

thank you for the detailed description. Concerning the lost values, it seems that the problem is related to the multiple instances of the Application::Values class. There is the global autoobject named Application::Values1 and an instance embedded in the component Application::Start and Application::NumKeyboard. These instance don't share their data. It means, whatever is stored in the instance inside the Application::Start component is not the same value in Application::Values1 autoobject.

For example, the code of the method Update in the component Application::NumKeyboard reads the values form the 'local' instance named Values1:

Assuming the expected values are stored in the autoobject, replace the expressions Values1 by Application::Values1. Then delete the locally existing instance of the object. Only the global autoobject should remain existing in the project as the unique global entity to store the data. Also review other components which eventually contain code to store/read the data values and modify the code to use the autoobject.

Please note: Embedded Wizard implements a garbage collection which destroys objects which are not in use anymore. This may cause the autoobject Application::Values1 to be freed and its data to be lost if there is no active referecne to the autoobject. Therefore, add a new variable to the Application component and configure its type to be object. Then assign the autoobject Application::Values1 to this variable. This creates a strong refernce to the autoobject and prevents its removal. See also Lifetime of an autoobject.

Concerning the Nozzle_Temp slot method, there is surely some code in your application triggering the method. Search your project for the name Nozzle_Temp and review all occurrences. You can also set a breakpoint at the beginning of the slot method and using the Callstack window investigate the invocation origin. However, if the slot method is triggered due to a postsignal, idlesignal or observer notification, the origin of the invocation can't be seen anymore. The Callstack window reveals in such case at least the class of the object which triggered the signal. See in the upper area of the Callstack window the row starting with sender.

I hope it helps you further.

Best regards

Paul Banach