Embedded (inline) behaviors for datagrids is not working

[slylabs13]

Hi all.

New here, thanks everyone for their efforts. In OpenXTalk datagrids out of the box work fine. However some time ago I attempted to insert a behavior between the datagrid behavior button and the datagrid library script only stack in the application bundle. It failed, but someone on the LC forum posted a fix that worked quite well, until the LC devs incorporated the fix in the commercial product. ALL my datagrids use a custom library inserted in this manner.

But OpenXTalk does not seem to have incorporated that fix, or else some other change was made to this fork to cause it to fail. I attempted to copy the modified datagrid library from before the fix, and that does not seem to alleviate the problem.

I am wondering who to talk to to address the issue, if anyone wants to take it up. The solution involved iterating through the behaviors to get to the actual datagrid library.

[slylabs13]

I'll save you all some time. It looks like a lot of work has gone into the datagrid library, both by OpenXTalk devs and Livecode devs to the point where they are divergent enough that it doesn't look like this would be an easy fix. I am probably the only dev using inline behaviors for Datagrids, so if I decide to use OpenXTalk at some point in the future, I will have to migrate my inline library calls to a library stack and set it as a front script or else explicitly dispatch or send to that library.

[OpenXTalkPaul]

Welcome!
There's two forks of the IDE going on here at the moment, OXT DPE and OXT Lite, with slightly different goals.

some other change was made to this fork to cause it to fail

That's entirely possible but...

It looks like a lot of work has gone into the datagrid library, both by OpenXTalk devs and Livecode devs to the point where they are divergent enough that it doesn't look like this would be an easy fix.

That is not currently an accurate thing to say about OpenXTalk, the only thing that I've changed in DataGrid library that is different from LC Community 9.6.3 is any instances of the word 'LiveCode', which I believe was mostly in it's docs and its demo stack. I don't think Tom has made any other changes to the DG library/stacks, but I expect he'll chime in if I'm wrong.

If you could give us more information about the problem and the fix I'd bet one of us could get around to patching it into the DG library.

I've previously (for a grid of buttons for making patterns) used custom behaviors with DataGrid but I did them in heavily modified COPY of a DG template stack. I'm not sure why you would need to insert a script into the message path in a particular order when you could just add that to the template on a per-project basis?

[tperry2x]

I don't think Tom has made any other changes to the DG library/stacks, but I expect he'll chime in if I'm wrong.

Yes, you are spot-on. I've not changed the Datagrids from what you'd find in a 'vanilla' copy of LCC 9.6.3 (other than having the option to turn them off in my preferences).

If there were improvements made to Datagrids after the 9.6.3 LCC was abandoned, then this explains why we don't have them as they won't be included in our LCC source & IDE project files.

[slylabs13]

That was my bad. I did a Sublime Text FileDiff and saw a lot of changes, but I now realize I was comparing OpenXTalk with the Current version of Livecode! DOH! I did note however that the location in the app bundle for the datagrid library behavior changed. Not sure if that matters.

Anyway, what I know for certain is that with OpenXTalk out of the box, datagrids with an inline behavior will not work. Also, if I replace the OpenXTalk datagrid library with the version I modified to get it to work, it still fails. If I replace the OpenXTalk datagrid library with the 9.6.13 (most recent) version of the library, it STILL fails.

The private function _ResourceStack is where the change was made. In my modified version, and also in the current LC version, there is a repeat loop to grok the actual datagrid library file. In OpenXTalk that loop does not exist. Here is the code:

/* Compute the resource stack. If there is a stack with the name
* `revDataGridLibrary` then that is the correct stack. Otherwise,
* traverse the datagrid's behavior chain to find a stack with the
* appropriate object on it (button "Data Grid" of group "Behaviors")
*/
private function _ResourceStack
if sResourceStack is not empty then
return sResourceStack
end if

if there is a stack "revDataGridLibrary" then
put the name of stack "revDataGridLibrary" into sResourceStack
return sResourceStack
end if

local theStack, theCharNo
put the behavior of me into theStack

repeat
if theStack is empty or \
there is a button "Data Grid" of group "Behaviors" of \
stack value(word -1 of theStack) then
exit repeat
else
put the behavior of theStack into theStack
end if
end repeat

if theStack is not empty then
put offset(" of stack", theStack) into theCharNo
delete char 1 to (theCharNo + 3) of theStack
end if

put theStack into sResourceStack
return sResourceStack
end _ResourceStack

BTW I am not expecting anyone to incorporate this change. I know I can work around it, and I understand that there are licensing issues, but I should point out that this modification was not originally conceived by Livecode LTD, but by one of the end users.

And to answer the question, "Why use an inline behavior," it's because future versions of the datagrid behavior would be viable, but if I copy the behavior, then add my own modifications once, then I would potentially have to do that for every new version that is released, or at least check for alterations in the dg behavior.

[OpenXTalkPaul]

And to answer the question, "Why use an inline behavior," it's because future versions of the datagrid behavior would be viable, but if I copy the behavior, then add my own modifications once, then I would potentially have to do that for every new version that is released, or at least check for alterations in the dg behavior.

On the other hand you could think of it as you're developing your own DataGrid-API based custom control, that's semi-self-contained and can easily be re-used, and use it just the the same as if it was in some other intermediate position in the message path. It's somewhat encapsulated being in the same stack as your custom DG Template substack that uses your custom behavior(s). But Yes you're right, if you were to do that you might still may have to update multiple instances where you've used this custom-DataGrid template, but that's only if a later version of the DataGrid API changes something and breaks it (and I don't think that's all that likely anytime soon).

In fact I made my highly customized UI and behaviors button grid version DG maybe about 12 years ago and it still works great, even when running on an Android TV! But when I added too many buttons to that grid it became very laggy slow so I've basically rebuilt that custom DG as a Widget since then.

Personally I'd like for OXT to have its own Widget-based replacement for what Datagrid is commonly used for. There's open-source available that would be very good starting points for such a customizable list displaying control.

Not that I have anything against DataGrid2, it's very good, and has the advantage of being super-easy to modify directly with the IDEs tools.

[slylabs13]

A Table based control seems fairly doable, but the forms based DG was a stroke of genius. The degree of control over the contents is not something I think you would be able to get in a widget, at least not one that is very efficient or compact. Being able to design virtually any row template is incredibly powerful, and the LC engine is optimized to display it efficiently.

One feature I like very much with a Datagrid is that the underlying data can have undisplayed columns. I put table query results into a datagrid, but only display the summary columns so I don't overwhelm the user with columnar data. As such it becomes a kind of database cache.

Also, the ability to sort by data types, drag reposition columns, edit in place etc. all seems like it would be a LOT of work to design a widget to mimic. And I'm not sure what the advantage would be. My experience with LC widgets is that they never do all the things that the control they were meant to replace do, or do as well. The Property Pallette is a great example.

[OpenXTalkPaul]

A Table based control seems fairly doable, but the forms based DG was a stroke of genius. The degree of control over the contents is not something I think you would be able to get in a widget, at least not one that is very efficient or compact. Being able to design virtually any row template is incredibly powerful, and the LC engine is optimized to display it efficiently.

One feature I like very much with a Datagrid is that the underlying data can have undisplayed columns. I put table query results into a datagrid, but only display the summary columns so I don't overwhelm the user with columnar data. As such it becomes a kind of database cache.

Also, the ability to sort by data types, drag reposition columns, edit in place etc. all seems like it would be a LOT of work to design a widget to mimic. And I'm not sure what the advantage would be. My experience with LC widgets is that they never do all the things that the control they were meant to replace do, or do as well. The Property Pallette is a great example.

Oh I think that the DataGrid is a fantastic API to have as part of OXT, Trevor Devore wrote it initially I believe.
And you can use widgets with it!

Have you seen the (commercial) extensions PolyGrid and PolyList or whatever? Like that. In fact at one point early on I had hopes those guys (https://github.com/Ferruslogic) would donate that work to OXT, but I can't blame them for tryin'ta make a buck.

The advantage with Widgets are the draw on the screen faster, even with many many elements (I tend to store SVGPath data in Arrays that get painted from), they can store data and have whatever custom properties you want just like 'classic controls' custom properties except you can make them editable with your choice of Property Inspector Editors for various data types (like giving a boolean a checkbox or enumerated lists pop-up menu editing in the PI).

Here's another advantage I don't think people would consider, you can actually embed the binary of an .lcm module into a stack and then on the stack user end who may not have the widget installed, the stac'ks preOpenStack script can load the module into memory and then use it. This means they can be treated in a way that's reminiscent of the old XMCDs/XFCN resources that would often be embedded in the resource forks of HyperCard Stacks 'back in the day'.

Oh and the degree of control practically limitless. A widget doesn't really do anything unless you code it to do something. You can make a 'Widget' that is just an empty rect with only the bare minimum default properties show in the property inspector, but that's not a very useful thing, to get it to display anything you use libSkia bindings within the language to draw on layers of canvas, often times that will be vector drawing paths, but could be image data too. Vector drawing is another advantage, vector path art can be very small amount of data and typically draws faster on screen than raster images. And its another big advantage vector drawing is infinitely scalable/resolution independent, which I think Is important in a world were pixel density of screens has increase exponentially over the past 15 years or so, we're in 8K display times now.