Using the @Device from devicebrowser on different pushed pages

Questions
#1

I am trying to understand how @Device.myproperty works across pages. I have run into this problem before but rather than fix it worked around it somehow. Sorry if I’m asking the question a second time - albeit in a slightly different scenario.

Eg devicebrowser with a few devices each with tiles and details tiles configured.

  1. On the tile @Device.myproperty exists and has the correct data for that device.
  2. On the details tile (opened by App Open details) the @Device.myproperty is present and correct.
  3. If I add a button on the device tile to push mypage.xaml the @Device.myproperty is not defined on the mypage.xaml. (If I directly reference the device eg Hall.myproperty - the value is present.)
  4. If I add the same button on the details tile to push mypage.xaml the @Device.myproperty is present and correct on mypage.xaml.

When/how does Device get setup to reference the device originally picked in device browser?
(I have tried the virtual variable work aroudn suggested elswehere but am getting something wrong and haven’t got that working yet.)

The problem I am trying to get around is that I want the original device tile to have about 3 buttons that take you to different pages of config for that device - allowing you to return to original tile when done.

#2

Not completely sure this will apply to your situation, but when in doubt and you push a page and know exactly what specific device needs to open, you can do a line feed and put the device name below it.

Device
Device1490×634 29.3 KB

#3

Hi. Not sure if I fully understand - sorry.

My problem was I have a device tile with 3 buttons to take me to different details pages referencing the same source device but allowing access to totally different sets of info that needs displaying or editing. One ‘details’ page is weekly heating schedule, one ‘details’ page is future heating events (it is for rooms that are available to hire - we get a booking and add the heating event in at the same time). the third ‘details’ page is a page of instructions.

Example - device rooms are in a group and got at via device browser. One of the rooms is ChurchHall.

I found that the @Device.someparameter worked correctly on the original ChurchHall tile and on the open details ChurchHall page. If I pushed a page directly from the ChurchHall tile the @Device was not defined so I couldnt get at ChurchHall parameters. I couldn’t find a way of making this work. (Weirdly, if I add a button on the details tile and push yet another page - the @Device is defined on that new page -child of a child.)

Workaround: I have three layers on the same details page. The buttons all reference app opendetails but also set a virtual variable defining which bits of the detail page are visible. The onload event on the details page hides or shows the bits needed. Its messy to edit but does work ok. Separate details pages would be a lot easier and cleaner if I could get that working.

#4

It all depends on your design but I would use page browsers. A separate page browser for each set of controls ideally that would occupy the same real estate and page in the design that get swapped out with eachother. Your device can be assigned to the page browse therefore the individual buttons or controls on the page browser can use @device. Check out my page browser video. It may spark some ideas.

#5

Thanks. I had looked at an example like this before but not made the link to what I was trying to achieve. I think I now do have a better grasp of this method.

However my workaround (a details page with 3 separate grids overlaid and either visible or not) is now pretty much complete so will stick with it for now. It was a pain to edit because the three totally different details views were on top of each other on the same designer view. (I kept editing the wrong item.)

I still wish I understood how @Device is used and when it is valid as this was the basis of my original design.

#6

It helps to name the elements as you add them with something unique to the group or layer then hide them temporarily so they can’t be selected.

1 Like
#7

Thanks. Was a bit lazy with this but I have now named all the items and that has made it more useable as a solution. Just added a fourth ‘overlay’ on the details page for another bit of settings input dialogue and getting better at NOT editing something on the wrong overlay!
Andy

1 Like
#8

WORKAROUND! Found a much better workaround.

I now have four buttons on the main device page (scheduler, event planner, help, override)
On each button click on the main device page I set a virtual variable to a name to indicate which details page I want to see and then open the details page for the device.

The details page does not have any content as such and its onloaded event checks the virtual variable. Based on its content I open one of 4 content pages for scheduler, event planner, help, override options.

When in these child pages the @Device correctly references the original devices correctly and the return button on each calls app pop page and returns me to the original device.

This has the advantage that the child pages are just contents pages without hidden or visible layers and much easier to manage and update.

To quote dire straights ‘whooo ooo oooo’!