Accessing Class Parameters

Question

Hi Team,

1. I have an application case to view the logged data from the device. Wen integrating with the device it should get the total no of logs and display the logs in a vertical list.  I have created some classes for common parameters and channel based parameters to access them from the device. According to the implementation common parameters like date and time get updated correctly for all the items but the channel based parameters have the same value for all the items.  I couldn't find the root cause for this issue. In Embedded Wizard can't we have the implementation like this? If not what could be the solution?

2. On the above implementation for example we need to have 1000 logs, but we will retrieve 10 logs at a time from the device and display in the viewing area of the outline. Consider a scenario that we have 500 total logs, when initiating the logs screen it will retrieve 10 logs and display them. But the vertical list will have the height of TotalLogs*VerticaList.ItemHeight. So the user can scroll the list more and we don't know where he will stop. When the user finishes scrolling, we need to find where he stopped the scrolling within the list and how many items have been scrolled. So that we can again retrieve the 10 logs for the left items. For example for 500 logs, Initially log 1 to log 10 is displayed. When I scroll I have stopped at a position where 103rd to 112 th log should be displayed there.  So how I can calculate this position and the itemNo to be there in that position? Is there anyway to find that one?

Regards,

Sazna.

Answer 1

Hello Sazna,

so far I understood your implementation, the log data is stored in array existing in a global autoobject LogArray1. The array entries themself are instances of the LogParameters class. The LogParameters class has variables for the Channel1..Channel3 values. These variables refer the global autoobjects Channel1Params, Channel2Params and Channel3Params. Consequently all LogParameters objects will have the same data in the Channel1..Channel3 variables.

I would recommend to avoid the global Channel1..Channel3 autoobjects. Use instead local instances of LogParameters embedded directly into LogParameters class. Or much simple, store the values MainMeasureValue and MainMeasureUnit directly in LogParameters avoiding so the overhead of additional embedded objects.

Concerning the second question, so far I have understood it, what you intent to implement will become complicated. You could implement slot methods for the events OnEnd of the Slide Touch Handler. In this manner you can react when the scrolling is finished. The actual scroll position can then be obtained by evaluating the property ScrollOffset of the Vertical List.

Assuming however, that the log data is already available in the device (it is stored in some memory in the device) I would recommend other approach. Here implement in DeviceClass a simple interface to query the number of existing logs and query the content of a log with a particular number. For example:

int32  GetLogsCount( void )
string GetLogDate( int32 aLogNumber )
string GetLogTime( int32 aLogNumber )
string GetLogMeasureValue( int32 aLogNumber )
string GetLogMeasureUnit( int32 aLogNumber )

This interface is composed of methods. See also Implementing a Device Interface: Command. The implementation of the methods limit to query the information stored in your device. Additionally add a System Event to the DeviceClass. The idea here: when new log entry is recorded in your device, just trigger the System Event. Nothing else.

Now, in the component Application::Logs (where the log data is displayed) modify OnLoadItem slot method to use the new interface explained above. It means, when the Vertical List asks to load the item with number itemNo, you invoke Application::Device.GetLogDate( itemNo ) to get the date and use the returned info in the initialization of the list item. Similarly other methods are invoked and the returned values used to get the respective information.

Finally, add a System Event Handler to Application::Log component. Connect this handler with the System Event object explained above. And implement the onEvent method for the handler. In the method perform following code:

VerticalList.NoOfItems = Application::Device.GetLogsCount();
VerticalList.InvalidateItems( 0, VerticalList.NoOfItems - 1 );

This implementation will ensure that the list updates when new log entries are recorded. I hope it helps you further.

Best regards

Paul Banach

Comments

Hello Sazna,

actually the component Application::Logs containing the Vertical List descends from Application::Menu. The menu however implements its own scrolling and layout functionality including its own Slide Touch Handler.

The Vertical List and the new Slide Touch Handler are configured as Embedded. This would be o.k. for regular items you want to be managed by the menu. It will however have the effect of the Slide Touch Handler and the VerticalList being arranged vertically one below the other. When the user touches the screen he/she does not hit the Slide Touch Handler of the Vertical List but the handler of the menu component.

The reason for using Menu component as base class for the list is not clear for me. Depending on your original intention you have two options:

1. Ensure that Application::Logs component doesn't descend from Application::Menu. It could be sufficient to change SuperClass of Application::Logs to Core::Group. Then don't forget to set the properties Embedded of the Vertical List and the Slide Touch Handler to the values false. Also arrange the size of the Vertical List to correctly occupy the area of the Logs components and ensure the Touch Handler overlaps it. Important: When you change the SuperClass to Core::Group the component Logs contains few inherited objects which now appear in Inspector window in red color and error messages are displayed. To fix this inheritance issue you have to delete the red members.

2. Pack the Vertical List and the Slide Touch Handler into a new component and use this component within the menu. In such case, also set the property Embedded the Vertical List and the Slide Touch Handler to the value false. The new component appears then in the menu as a regular menu item - if this was your intention.

An additional observation: in the method OnStart you perform VerticalList.NoOfItems = 0. This will have the effect of the list being cleared just in the moment when the user starts the scrolling. I don't think it is your intention.

I hope it helps you further.

Best regards

Paul

---

Hi Paul,

1.When considering your alternative approach of having commands, How the memory can be managed for 10000 of log data's? for this concern only we are retrieving the data 10 by 10 for every scroll.

2.When I go for the option 1 of the above command, we will retrieve logs 10 by 10, so the array contains 10 entries. but if we want to have the scrolling we need to configure the no of items of the vertical list to total no of logs. If the total no of logs exceeds over 10, then the list loads the onload item equal to total no of logs. Hence the simulation is halted due to non initialized array member. Is there any solution to overcome this?

Regards,

Sazna.

---

Hello Sazna,

1.When considering your alternative approach of having commands, How the memory can be managed for 10000 of log data's? for this concern only we are retrieving the data 10 by 10 for every scroll.

the storage of the log entries is up to you. The Vertical List caches only the visible items and reloads them automatically when the user scrolls the list. Please read once more the chapter Vertical List explaining the functionality. Note the OnLoadItem slot method which has exact the job to load the necessary (actually visible) items.

Assuming the user should be able to scroll through thousands of log entries, it will be inevitable to store all log entries in a kind of data base. The simplest is to implement this storage in C code inside your middleware, for example as an array or as a list of chained data structures. I suppose you have already such kind of storage otherwise you would not be able to plan the scrolling of log entries.

Then the Vertical List limits to load the entries which are actually visible on the screen. This is the task of OnLoadItem. When the user scrolls the list, OnLoadItem is invoked for each item which is not yet cached in Vertical List automatically. Items which become invisible are automatically discarded from the Vertical List. You don't need to take care of it. This is a very simple interface.

With this approach the Vertical List only needs to know how many items are available in the storage (specified in its property NoOfItems) and you have to implement OnLoadItem so the list can load the necessary items at the runtime. The interface mentioned in my first answer is just an abstraction of the communication between the Vertical List and the storage implemented outside the GUI (in your middleware). It is an interface to query the number of actually existing log entries and to query their contents.

2.When I go for the option 1 of the above command, we will retrieve logs 10 by 10, so the array contains 10 entries. but if we want to have the scrolling we need to configure the no of items of the vertical list to total no of logs. If the total no of logs exceeds over 10, then the list loads the onload item equal to total no of logs. Hence the simulation is halted due to non initialized array member. Is there any solution to overcome this?

I think it is a misunderstanding of the Vertical List concepts and the associated examples. The Vertical List does not store the data by itself - it requires you to take care of the underlying storage where even thousands of data items could be managed. The interface to this storage is OnLoadItem slot method. To explain this technique in our examples we use arrays as the storage. This approach is however also applicable in practice if the number of data entries is deterministic. You could for example, configure the array to be able to store 1000 items. Then when new log entries arrive, just copy them to the next free entry in the array and increment NoOfItems. The new entry will automatically appear at the end of the list.

However, arrays in Chora have a disadvantage of having static size. It is not possible to resize the arrays dynamically at the runtime. When the 1001 item arrives there no free space anymore for it in an array configured for 1000 items. So following this approach you would need to configure the array for the maximum number of log entries you expect at the runtime ever. This memory will then be occupied even if there are only few log items recorded. Therefore it can be more convenient to implement own storage outside the GUI (in C code for example) where the items and the memory management is handled more efficient.

Does it help you to better understand the idea?

Paul

---

Hi Paul,

Could you please provide me an example project demonstrating the answer you have given to my 2nd question. I found difficult to implement and get the the desired functionality.

Regards,

Sazna.

---

Hello Sazna,

you can find an example demonstrating the approach here. Important detail: this example shows the application case of all log data being stored 'outside' the GUI application. To access the data a dedicated interface is defined. This interface needs to be implemented to read the log entries wherever they are maintained in your devices. For demonstration purpose, during prototyping the interface returns some dummy data.

For details see the comments inside the project and the methods. If something is unclear, don't hesitate to ask. I hope it helps you further.

Best regards

Paul