LiveCode Forums.

As per the title.

Whatever I have done so far - the widget chart always ends up obscuring the field I want to place in front of it. Even if I create that field AFTER drawing the chart widget.

Bruce

Hi Bruce,

you are talking about the new Chart widget in LC 10.x, right?
I can confirm this behaviour and consider this a bug.

Please report it here: https://quality.livecode.com

Best

Klaus

You could try GROUPING the chart widget . . .

richmond62 wrote: ↑

Thu Jun 06, 2024 11:40 am

You could try GROUPING the chart widget . . .

Doesn't work!

Then, whoever made the chart widget is breaking a few unspoken rules.-
- -
https://livecode.com/livecode-10-dp-2-c ... -and-more/

Surely ALL LC objects should "behave nicely" insofar as they can have their layer set, and other objects can have higher layers so they can be displayed in front of lower layers?

If you are talking about the chart widget in LC 10.xx then this would be the expected behavior unfortunately.

The LC10 chart widget is a html and JavaScript combination which is displayed in a browser, so it will be the behavior of the browser that stops overlays.

AHA!
Thanks for the info!

Thanks for all that. I get it. Not going to report it as a bug (it was suggested I do) because it seems that later on this is expected behaviour and thus not a bug - more an inconvenience.

The good news is that the chart widget lets the LC community tap into vastness of the JavaScript community, using an embedded browser instance to deliver the high-quality charting we see in some of the better JS apps.

The bad news is that browsers are complex, esp. with regard to rendering, so using them inside of LC takes the same route as embedded video players, granting the rendering full control within its display rectangle without attempting to interleave it with LC's own rendering/buffering queue. The result allows rendering performance nearly on par with what we'd see in a browser app directly, but as the cost of not being able to layer LC controls on top.

In short, as you've already found, this is indeed a known limitation, and not technically a bug. It just represents the trade-offs of using two different engines in one application.

However, if what you want to overlay can be created in JS (pretty much anything can), and if you're up for some deep diving into the charts widget, you may be able to add your own hooks to render other objects in addition to the chart using HTML/CSS/JS.

Given the size of the web dev universe, finding learning materials isn't hard for that. But modifying the chart widget may be murkier, relying on what LC Builder docs there are and comments within the chart widget code.

All that may be more work than it's worth. Just wanted to add the background on why this rendering limit exists, and at least point out possibilities for extending the widget if that ever becomes truly necessary.

Richard.

It is so good to have you around...

Craig

dunbarx wrote: ↑

Mon Jun 10, 2024 12:26 am

Richard.

It is so good to have you around...

Craig

Mutual.

It's not just 'Chart Widget' that's going to exhibit this behavior but ANY widget that uses 'Native Layer'. HTML5 'native' layers get rendered in their own 'canvas' element. MacOS, iOS, Android, and Linux GTK (a widget by me) Native Buttons and Native Fields all exhibit this same layer overriding behavior.
'Regular' (not-Native Layer) widgets on the other hand should work as expected and render the same way on any device (provided it does't use fonts that aren't installed).

You could also layer another native control over the chart. I’ve seen examples before that used another browser widget with transparent background to overlay something over another native control. I’ll see if I can locate any of those examples.


EDIT: Here's a link to the post...
viewtopic.php?f=93&t=29018&p=172789&hil ... 7e#p172789

How extremely sneaky ("sneaky" here is a compliment on a par with "brilliant" but with a slightly entrepreneurial rule breaking / rule working around streak.). Thanks.