I’ve gotten some terrific help from the folks here setting up quite a heavily customised Easy Chart object, but there are a couple of things I can’t seem to resolve.
I have the “X-Trace Track Mouse” property bound to a check box on the window, so the user can quickly turn it on and off. It works fine in designer, but on the client, whenever I open the window, the console logs the message “Error finding property setter method for binding on [trend object]”. If I try to check or uncheck the box on the client, the trend gets a “Config Error” overlay. What could be causing this?
The realtime range selector doesn’t seem to scale correctly. I’d ideally prefer that object to not scale at all and to just remain underneath the trend at the same size no matter what the trend gets up to. But if I create the trend full size then scale down, it’s unuseably small. If I create the trend small and scale up, it’s way oversized. The text also doesn’t seem to scale with the dropdown box. Is there any way to overcome this? I could roll my own entry fields to do the same thing, only I can’t find a way to pause/resume the trend by scripting, and I can’t find a way to turn the other entry fields off to put my own there anyway
The chart mode is not the property I’m trying to bind. I can set/get the chart mode just fine. What I’m trying to set is a boolean property of the chart which changes the behaviour of X-Trace mode. When the chart is in X-Trace mode, if this property is true, the X-Trace line will automatically follow your mouse across the chart as you move it. If the property is false, you have to click to position the X-Trace, then you move the mouse and it stays put. You click somewhere else to re-position it.
So this all works in designer, but not in a client.
I tried scripting, and whichever way I try it, if I try to change the value of trend.xTraceTrackMouse (where trend is a reference to the easy chart), I get the error that the trend object has no attribute ‘xTraceTrackMouse’. I can change it to write to trend.[some other bool parameter] and it works just fine, so it’s definitely pointing to the correct object, but for some reason the script doesn’t believe that it has that attribute. This applies in the designer as well as in the client - same error in both cases.
I will post some screenshots of issue #2 (scaling)
Two screenshots attached. Basically, I want to create the trend window so that it will scale well to any size screen (within reason). Let’s say I want it to work at both 800x600 and 1920x1280. So, I can create the trend window as a fullscreen window at 800x600, and have it automatically scale up when opened on a 1920x1080 monitor. Or, I can create it at 1920x1080 and have it automatically scale down when opened on an 800x600 monitor. Whichever approach I take, everything scales up or down perfectly, and looks just fine, except the realtime unit selector. If I create small and scale up, it’s comically large. If I create large and scale down, it’s unreadably small. In both cases, the spinner box and the dropdown menu scale at different rates and so regardless of their size, look funny.
Scripting it with a capital X works. Thanks! That’s obviously a bug as if you use the property selector to pick that property in the scripting window, it drops it in with a lower case X (and also it shows the scripting name with a lower case X in the property panel). Perhaps the same issue is at the core of the binding not working.
Do IA have a procedure for reporting bugs that I should poke this toward?
In any case, the scripting workaround has that problem solved. Any clues on the scaling issue?
FWIW, I usually make a chart that fills the whole window, and set it to anchored layout, with all four edges locked. Then the chart resizes to follow window resizing, but all of the fonts stay the same size.
Interesting. In that mode, the scaling works correctly. However, it breaks one of my other “features”…
When in realtime mode, the chart graphic area gets slightly shorter, to allow space underneath for the “last x minutes” selector. When switched to manual mode, the chart graphic area gets taller as those controls disappear.
When I switch to manual, I reduce the height of the chart object as a whole by 34 pixels. This means that the chart graphic area remains exactly the same, and in the space where previously there was a “last x minutes” selector, there has now appeared a “start date”, “end date” and some scroll buttons. When I switch back to realtime, I increase the height of the chart object by 34 pixels and the manual controls disappear. The idea is that you switch modes, the trend graphic looks identical, just the controls change to suit the mode.
This works when the chart is set to relative layout. On a fixed layout, the resizing does not behave the same.
Here’s my code, is there a simple way to tweak it to work with an anchored layout?
if event.oldValue == 0 and event.newValue <> 0:
system.gui.transform(trend,newHeight = trend.Height + 34)
if event.newValue == 0 and event.oldValue <> 0:
system.gui.transform(trend,newHeight = trend.Height - 34)
Put the trend object in a container by itself, the same size as the container
Have the trend object layout anchored to all four sides of the container
Have the container layout set to relative, don’t maintain aspect ratio
Transform the size of the container, not the trend
Scaling of the realtime controls is correct, and I can adjust the size of the chart area to put my buttons underneath.
Workarounds in both cases, but at least there is one!
