MainLobby Designer Bug Reports

Topics related to the new MainLobby Web Designer software for Android and iOS devices.
RZajcew
Intermediate
Intermediate
Posts: 257
Joined: Mon Jul 21, 2008 6:31 pm
Contact:

Re: MainLobby Designer Bug Reports

Postby RZajcew » Sat Jul 05, 2014 4:28 pm

I am editing a scene based on the climate.html iPhone scene in MainLobby. And I am seeing some "questionable" behavior.

1. The gauge object has a couple of images on top of it (snowflake/flame/etc). When I edit the gauge object, it moves the gauge object to the front. And the gauge object stays on the front when I save the file. I can't imagine that this is desirable behavior.

2. The object has the "LCD Visible" property checked, and the LCD is visible in Chrome. However, when I open the gauge object in the designer, the "LCD Visible" property gets automatically unchecked. Rather surprising.

3. The gauge variable seems to have some difficulty with the number sometimes. [I've seen it work] Currently I have it set to {{therm_{{therm_zone_{{clientname}}}}_spc}} and the LCD says "NAN" (Not A Number). I am displaying the number as a text string right next to the gauge and the number reads "78". [I've also checked the values of the MLServer variables, and indeed this adds up to "78"].

Regards,
Roman

User avatar
CinemarDave
Site Admin
Site Admin
Posts: 10535
Joined: Fri Feb 07, 2003 8:56 am
Location: Planet Earth
Contact:

Re: MainLobby Designer Bug Reports

Postby CinemarDave » Sat Jul 05, 2014 5:17 pm

I can't imagine that this is desirable behavior.

Not desirable but an unfortunate fact of life. Every time the gauge object gets modified it must be destroyed and recreated on the page. When this happens the new gauge automatically gets appended to the page. Therefore it automatically floats to the top of the z order. This is why all the objects that were placed on the gauge go to the back. So the rule of thumb when creating gauges is to get your gauge functioning well before the final decorations are placed on it. Gauges are entirely created in memory using an HTML Canvas object. That's why I'm forced to destroy it and re-create it.

As for the other items I will investigate.

RZajcew
Intermediate
Intermediate
Posts: 257
Joined: Mon Jul 21, 2008 6:31 pm
Contact:

Re: MainLobby Designer Bug Reports

Postby RZajcew » Thu Jul 10, 2014 10:49 pm

I have noticed that certain panel object refuse to have the "Gradient" property stick. That is, you are allowed to click the Gradient button for the panel, but when the panel is closed the Gradient button gets unclicked (and of course there is no gradient).

One example of such a panel object is the security keypad outline in iPhone\Security.html.

Regards,
Roman

User avatar
CinemarDave
Site Admin
Site Admin
Posts: 10535
Joined: Fri Feb 07, 2003 8:56 am
Location: Planet Earth
Contact:

Re: MainLobby Designer Bug Reports

Postby CinemarDave » Fri Jul 11, 2014 10:14 am

The reason you are seeing that is because the background color of that panel has been set to pure black. We cannot make a gradient when starting with pure black. You will see the same thing happen when choosing pure red, blue, green and white.

RZajcew
Intermediate
Intermediate
Posts: 257
Joined: Mon Jul 21, 2008 6:31 pm
Contact:

Re: MainLobby Designer Bug Reports

Postby RZajcew » Sat Jul 12, 2014 2:47 pm

For a button with a left-justified label, leading blanks in the label are ignored. Certainly this happens when the label is an MLServer variable (my use case).

This behavior is different than the behavior in MainLobby.

Perhaps this is inherent in the browser, but I was hoping not.

- Roman

User avatar
CinemarDave
Site Admin
Site Admin
Posts: 10535
Joined: Fri Feb 07, 2003 8:56 am
Location: Planet Earth
Contact:

Re: MainLobby Designer Bug Reports

Postby CinemarDave » Sat Jul 12, 2014 4:55 pm

This is the HTML specification. Leading and trailing spaces in strings are considered white space and do not occupy markup. If you need leading and trailing spaces use the HTML code for a non-breaking space  

User avatar
ronsatter
Is there life beyond Cinemar?
Is there life beyond Cinemar?
Posts: 1304
Joined: Mon Dec 04, 2006 1:40 am
Location: San Leandro, CA
Contact:

Re: MainLobby Designer Bug Reports

Postby ronsatter » Sat Jul 12, 2014 8:38 pm

CinemarDave wrote:This is the HTML specification. Leading and trailing spaces in strings are considered white space and do not occupy markup. If you need leading and trailing spaces use the HTML code for a non-breaking space  


Ahah! So that is what "nbsp" stands for. I troll the forums day and night for moments like this 8)

Ron
If it ain't broke ... don't fix it!

RZajcew
Intermediate
Intermediate
Posts: 257
Joined: Mon Jul 21, 2008 6:31 pm
Contact:

Re: MainLobby Designer Bug Reports

Postby RZajcew » Sat Jul 12, 2014 10:28 pm

When a button is clicked, the button momentarily is outlined in red, and then returns to normal. Which is fine.

I have one overlay where, after almost any button is clicked, the red outline persists. The overlay has 10 buttons, 8 of which exhibit this characteristic (of a persistent red outline), and two of which behave normally.

If I start over again with the browser, the red outline is gone. But the red outline persists if I click the same buttons again.

As far as I can tell, there is absolutely no difference between the buttons -- one of the buttons that is fine is "identical" to 7 other buttons, and the other button that is fine is "identical" to the other misbehaving button.

This happens on Chrome on the server and on iPhones.

- Roman

RZajcew
Intermediate
Intermediate
Posts: 257
Joined: Mon Jul 21, 2008 6:31 pm
Contact:

Re: MainLobby Designer Bug Reports

Postby RZajcew » Sat Jul 12, 2014 11:16 pm

On another scene (not an overlay, as it happens), I have two buttons next to each other labeled "OFF" and "COOL".

Both buttons use the state variable {{therm_{{therm_zone_{{clientname}}}}_m}} In both cases I am use "On Values" (rather than "Off Values").

On one button, if the value is "O", then the button has an opacity of 50% (rather than 100%). On the other button, if the value is "C", the label color is Blue (rather than White). And I am looking at the browser right now, with one button being 50% and the other button being Blue. Shouldn't be possible, I think.

As a point of fact, the value of {{therm_{{therm_zone_{{clientname}}}}_m}} happens to be "O" in this case.

Regards,
Roman

User avatar
CinemarDave
Site Admin
Site Admin
Posts: 10535
Joined: Fri Feb 07, 2003 8:56 am
Location: Planet Earth
Contact:

Re: MainLobby Designer Bug Reports

Postby CinemarDave » Sun Jul 13, 2014 10:47 am

Whenever you click on an object and the red halo does not go away it means one of two things
1) The JavaScript tied to the click event has failed. (Not too likely but you can check this by looking at Chrome's Developer Tools Console output)
2) There is a duplicate object ID. (Most likely cause) Make a copy of the object and delete the original to see if that resolves the issue.

RZajcew
Intermediate
Intermediate
Posts: 257
Joined: Mon Jul 21, 2008 6:31 pm
Contact:

Re: MainLobby Designer Bug Reports

Postby RZajcew » Sun Jul 13, 2014 11:36 am

CinemarDave wrote:Whenever you click on an object and the red halo does not go away it means one of two things
1) The JavaScript tied to the click event has failed. (Not too likely but you can check this by looking at Chrome's Developer Tools Console output)
2) There is a duplicate object ID. (Most likely cause) Make a copy of the object and delete the original to see if that resolves the issue.


1) The Chrome Developer Tools Console shows nothing.
2) I assume that the "object ID" is the title at the top -- something like "button1691"? I went through all the objects, and they were all unique. The buttons go from "button1659" to "button1692" sequentially.

Regards,
Roman

User avatar
CinemarDave
Site Admin
Site Admin
Posts: 10535
Joined: Fri Feb 07, 2003 8:56 am
Location: Planet Earth
Contact:

Re: MainLobby Designer Bug Reports

Postby CinemarDave » Sun Jul 13, 2014 11:41 am

You also have to take into consideration the object IDs on all the embedded overlays too. Did the copy / paste / delete original test work?

RZajcew
Intermediate
Intermediate
Posts: 257
Joined: Mon Jul 21, 2008 6:31 pm
Contact:

Re: MainLobby Designer Bug Reports

Postby RZajcew » Sun Jul 13, 2014 12:00 pm

CinemarDave wrote:You also have to take into consideration the object IDs on all the embedded overlays too. Did the copy / paste / delete original test work?


That was it. Thanks. One overlay's object ID range was overlapping another overlay's object ID range.

Just asking, but shouldn't the Designer somehow try to prevent this? Perhaps, when creating an object in a scene, it could somehow include a 3-digit hash of the scene name in the object ID, so that chances of overlap are minimized?

Regards,
- Roman

User avatar
CinemarDave
Site Admin
Site Admin
Posts: 10535
Joined: Fri Feb 07, 2003 8:56 am
Location: Planet Earth
Contact:

Re: MainLobby Designer Bug Reports

Postby CinemarDave » Sun Jul 13, 2014 1:47 pm

The designer goes to great lengths to overcome the dupe id issue. In order to create a new ID it hashes the full path to the overlay and the number of elapsed seconds in the current day. It usually does a good job. The algorithm falls apart if one of the sample overlays is copied into the live project.

RZajcew
Intermediate
Intermediate
Posts: 257
Joined: Mon Jul 21, 2008 6:31 pm
Contact:

Re: MainLobby Designer Bug Reports

Postby RZajcew » Sat Jul 19, 2014 12:09 pm

RZajcew wrote:On another scene (not an overlay, as it happens), I have two buttons next to each other labeled "OFF" and "COOL".

Both buttons use the state variable {{therm_{{therm_zone_{{clientname}}}}_m}} In both cases I am use "On Values" (rather than "Off Values").

On one button, if the value is "O", then the button has an opacity of 50% (rather than 100%). On the other button, if the value is "C", the label color is Blue (rather than White). And I am looking at the browser right now, with one button being 50% and the other button being Blue. Shouldn't be possible, I think.

As a point of fact, the value of {{therm_{{therm_zone_{{clientname}}}}_m}} happens to be "O" in this case.

Regards,
Roman


I noted this behavior still exists. So I went back and looked at this more carefully.

What I have is a button with a black background and a white label, labeled "COOL". The behavior of the button is such that if the state variable {{therm_{{therm_zone_{{clientname}}}}_m}} has an On value of C, the label color changes to blue (the background color and opacity stay the same). The command for the button (as one might guess) changes {{therm_{{therm_zone_{{clientname}}}}_m}} to C (along with other things). I save the scene.

The initial value of the {{therm_{{therm_zone_{{clientname}}}}_m}} is O. And the scene displays correctly (with a white label) from either Chrome or from an iPhone. When I hit the button, the variable {{therm_{{therm_zone_{{clientname}}}}_m}} changes to C (as expected) and the color of the label changes to blue (as expected).

What is not expected is that the "Label Format" color permanently changes to blue. That is, if I now look at the page from MainLobby Scene Designer, Label Format now has a blue color. And the only way to "correct" this is to edit the page via Button Properties.

Totally repeatable.

Regards,
Roman


Return to “MainLobby Web Designer (V5)”

Who is online

Users browsing this forum: No registered users and 1 guest