openHASP icon indicating copy to clipboard operation
openHASP copied to clipboard

jsonl parsing - duplicate objects

Open smcgann99 opened this issue 1 year ago • 3 comments

Perform all steps below and tick them with [x]

  • [X] Check the related part of the Documentation
  • [X] Update openHASP to the latest version
  • [X] Reproduce the issue and describe all steps

Describe the bug

Sending jsonl for an object twice should first add and then update attributes for the existing object, However when changing its parentid it then creates a second object with the same id, also then allows for obj type to change, so I can create a label and a button with the same id on the same page, in 2 different parents.

To Reproduce

  { "page": 2, "id": 1, "x": 0, "y": 0, "h": 100, "w": 100, "obj": "label", "text": "parent 1", "bg_color": "#DfDf00", "bg_opa": 255 },
  { "page": 2, "id": 2, "x": 110, "y": 110, "h": 100, "w": 100, "obj": "label", "text": "parent 2", "bg_color": "#DfDf00", "bg_opa": 255 },
  { "page": 2, "parentid": 1, "id": 3, "x": 20, "y": 20, "h": 40, "w": 40, "obj": "label", "text": "child", "bg_color": "#550000", "bg_opa": 255 },
  { "page": 2, "parentid": 2, "id": 3, "x": 20, "y": 20, "h": 40, "w": 40, "obj": "btn", "text": "child", "bg_color": "#550000", "bg_opa": 255 },

Expected behaviour

A second object should not be created, the original object should just be updated.

Screenshots or video

smcgann99 avatar Oct 12 '24 15:10 smcgann99

I think this is not a mistake for two reasons:

  • The type of the object cannot be changed afterwards. That makes no sense. Different objects in memory use the memory reserved for them differently. This is only possible if the object is deleted from the memory and another object is created.

  • The ID is always valid for the parent object. For ID 1 and 2, it is the page. For label ID 3 it is label ID 1, but for button ID 3 it is label ID 2, which is why a new object is naturally created.

Simply test Parentid = 1 for both objects. You can see that no new object is created and all properties that both the label and the button have in common are adopted.

Translated with DeepL.com (free version)

marsman7 avatar Dec 06 '24 17:12 marsman7

I understand what you are saying, but regardless of the parent id there are now 2 objects on page 2 with ID 3. So any interactions with them both report as ID 3, and any update to properties are applied to both. which is a bit messy and confusing.

Obviously this wasn't a design decision just a typo, but it would be better is this was handled when parsed, with a warning and no update to the page ?

smcgann99 avatar Jan 25 '25 16:01 smcgann99

Yes, you could add a warning to the programme for this case, but I think it takes a lot of time. For each new object, all old objects would have to be checked to see if the ID matches and the type does not match. I'd rather have the designer pay attention and restart the device faster.

marsman7 avatar Jan 25 '25 17:01 marsman7