Data Grid.. first impressions

LiveCode is the premier environment for creating multi-platform solutions for all major operating systems - Windows, Mac OS X, Linux, the Web, Server environments and Mobile platforms. Brand new to LiveCode? Welcome!

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

Post Reply
massung
Posts: 93
Joined: Thu Mar 19, 2009 5:34 pm

Data Grid.. first impressions

Post by massung » Thu Apr 09, 2009 4:23 am

This was the feature I've been waiting for the most. After downloading 3.5 and trying it out for the past 2 hours, here are some basic thoughts on it.

It's a great idea, concept, and I'm glad it's there. Bravo. And with the link posted in the other thread, it was remarkably easy to get one going.

That said...

Note: I do know the answer to many of these having read the documentation after my initial dive-in. I just wanted to see how easy the use of the data grid was. I still believe - even after going through the docs - that many of these still are issues.

It took me all of 10 minutes playing around with it to hard lock up Rev. Admittedly there will be bugs, I'm sure. But even using "top" and "kill" from terminal in OS X failed to kill Rev. Note: this was caused by modifying the basic template and following the tutorial to fill the dg with data. However, I forgot to modify my layoutControl handler, which didn't find the controls that it defaulted with. Bad times. :(

Buttons I place in my row template can't be debugged. Perhaps this can be worked around by just making them call commands on another stack somewhere, but was a serious bummer - especially while still learning how to use it and didn't know if I was doing things right.

It was disappointing that I couldn't reference the other controls in the row template group by name and have it "just work." For example, if I added a button in the template that would answer the text of a field in the template, I couldn't just do:

answer the text of field "foo"

Well, I could, but it always returned field "foo" of row 1, instead of the group row the script executing was on. Instead, I needed to access the actual entry from the dgData. That's fine for the control properties that get set by dgData, but what about the ones that don't? What if I wanted to change the background color of the field when I clicked the button?

If I modify the row template (even just a script in the template), I need to click "Refresh Data Grid" to get those changes to take effect. This took me a while to figure out on my own. Not a big deal, but definitely an extra step that was a minor annoyance.

I found it sad that the geometry manager doesn't work [well] for the row templates. I'm sure this isn't an easy problem to solve, and is why so much control was put in the hands of the programmer with layoutControl. Still, it would have made life so much easier if it did.

Aesthetically, I think it's quite sad that the dg control doesn't follow any of the regular Rev property conventions. Properties are named with spaces in them (like "allow editing" and "alternate row colors" as opposed to "allowEditing" and "alternateRowColors"). This means I can't use the get command on the dg like I can every other control. Or, if I can, it isn't so obvious how. I later discovered these are accessed through dgProp custom property. Still...

Similarly, do the dg properties begin with "dg." If that was the convention throughout Rev, that'd be cool (and I prefer it in my C code). But that isn't the Rev convention. So it really sticks out with a sore thumb. I don't do:

set the fieldText of field "foo"...

So why should I be doing:

set the dgData of group "foo"...

instead of:

set the data of group "foo" ...

I'm sure there are reasons behind it. And I've only been playing with the control for an hour or two, so hopefully someone can just enlighten me. ;)

Here's hoping the data grid evolves into something wonderful!

Jeff M.

trevordevore
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1005
Joined: Sat Apr 08, 2006 3:06 pm
Contact:

Post by trevordevore » Fri Apr 10, 2009 5:43 am

Hi Jeff,

Thanks for taking time to post about your first experience with the data grid. It is very useful to know what people experience when they first encounter something for the first time as it can help improve the experience in the next iteration. I will try and explain why some of the things you noticed act the the way they do (I wrote the underlying data grid library).

I will begin by saying that the data grid is something that is best experienced by reading the docs first :-) It would be great if you could get up and running without any but the reality is the the data grid uses some concepts in the Revolution engine that many people haven't been exposed to before. Behaviors is one and using groups to represent each row in a list is another.

Also, because the data grid allows you to display your data just about any way you like it does involve more steps than other Revolution controls. I think (I hope at least) that you will find that creating data grids becomes fairly straightforward once you have done it 2 or three times.

So, on to some of your observations.

1) Referencing controls in a row template: 'of me' will become your new best friend. Because your row template is being copied many times any references you make to your controls in your row template will be ambiguous if you don't tell the engine exactly where they are. 'of me' does exactly that. If your template scripts reference field "Name" of me then the engine knows that it is the field "Name" in that particular group.

2) Data grid properties: It would be great if the data grid could have properties like native Revolution controls. A data grid is actually just a group that uses the new behaviors feature in 3.5. Given the current way the Revolution engine works that means you have to rely on custom properties in order to define properties for the data grid. I decided to use a custom property set named dgProps whose keys you set in order to change the majority of the general properties:

Code: Select all

put the dgProps["allow editing"] of group "Data Grid"
The alternative would be something like this:

Code: Select all

put the dgAllowEditing of group "Data Grid"
The "dg" prefix is used to distringuish properties used by the data grid library from custom properties that you the developer might assign to it and also to keep any data grid properties from colliding with current or future properties defined by the engine (hence 'dgData' rather than just 'data'). Personally I find the first example to be easier to read than the later when scanning code. It isn't ideal but it is the way it is.


3) Use of geometry manager: Having all of the resize code in LayoutControl is going to speed things up as you aren't relying on a generalized library to figure out where controls should go. You are just telling the controls exactly where they should go. This has the benefit of being very fast which is a very good thing for a control like the data grid. That being said, I can understand wanting to quickly tell your controls where to go and what to do without having to write any code.

I will point out for other readers that the geometry manager does work for the data grid as a whole, just not for data grid row/column templates.

4) Needing to click "Refresh Data Grid": Can you describe how you expected the data grid to update? Were you hoping it would update each time you compiled the behavior script? Each time you moved controls around in the template? Some other time?

5) Debugging: This is a sticky area. The Revolution IDE doesn't report errors in stacks that have a rev prefix and I don't think it debugs it either. The code in your row behaviors is called from with the revDataGridLibrary stack. Right now we display an answer dialog when in the dev environment and points you to the script but it would be ideal if normal error handling occurred. The hard locks seem to be related to the debugger somehow though I'm not exactly sure what caues it. I saw it once today but I don't see it all of the time. Hopefully we can make some improvements in this area going forward.
Trevor DeVore
ScreenSteps - https://www.screensteps.com

LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder

sturgis
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 1685
Joined: Sat Feb 28, 2009 11:49 pm

Post by sturgis » Fri Apr 10, 2009 6:28 am

There seems to be a work around for the hard lock problem. At least it has helped me get past it. If I get an answer dialog stating theres a message, I click ok, it hightlights, if theres more than one, ok again, then immedietly go to the development menu and uncheck script debug mode, click my datagrid to select it (browse mode) and then turn script debug back on.

If I don't do this, and keep messing around with things, the likely hood of a lock seems pretty high. No clue why this helps, and its a pain, but hey. Its better than a hard lock. Could probably just leave script debug mode off which isn't a great answer either.

My 2c worth.

Bernard
Posts: 351
Joined: Sat Apr 08, 2006 10:14 pm

Post by Bernard » Fri Apr 10, 2009 11:38 am

After using Rev for 6 or 7 years, I like to think I'm pretty au fait.

When the new data grid came out, I found it hard to work with just using what came in the 3.5 beta. After seeing Trevor's docs things became more clear.

However, the thing that really made a huge difference to my understanding was downloading the webinar that Trever and Kevin took part in.

I really think that is the right starting point for people trying to grasp the data grid. I would hope to see that webinar highlighted in the forums and on the Rev site (and maybe even in Trevor's documentation).

trevordevore
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1005
Joined: Sat Apr 08, 2006 3:06 pm
Contact:

Post by trevordevore » Fri Apr 10, 2009 3:44 pm

Bernard - good point. I just added the link to the Revolution 3.5 portion of the site and the webinar video to the right column of the documentation table of contents.
Trevor DeVore
ScreenSteps - https://www.screensteps.com

LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder

massung
Posts: 93
Joined: Thu Mar 19, 2009 5:34 pm

Post by massung » Fri Apr 10, 2009 4:18 pm

Trevor,

Thanks for the followups. I learned about the 'of me' later on. Yes, it is helpful. ;)

With regards to the dg prefix on properties, I think here we must agree to disagree. It's very much against all the other properties in Rev and I feel like I'm back to programming C, sadly. Shoot, they aren't even highlighted by the script editor as real properties. The same goes for the custom properties. Why oh why did they need to be named outside the rest of the Hypertalk conventions? :(

If there needed to be a way of differentiating data grid properties from other properties, adding a new filter to the command syntax would have been much more preferable. Consider the open command:

open file ...
open socket ...
open secure socket ...

One doesn't do:

open socket ...
set skSecure of ...

Perhaps adjectives for the datagrid properties would be a welcome addition and keep with the Hypertalk spirit (much like "secure" is used above)?

Lastly, while it's really "cool" that the datagrid is really just something that sits on the top of what Revolution can already do, having it written in Revolution can also allow the user to really muck things up unwittingly (and to be frank, Rev is designed for the those w/o CS degrees). With the datagrid, this comes in the form of the pre-created script behavior. Like the getID property (sorry, I don't remember the actual property name off hand). What happens if I delete this accidentally or return something different?

Still. It's a nice feature, and thank you for adding it.

Jeff M.

trevordevore
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1005
Joined: Sat Apr 08, 2006 3:06 pm
Contact:

Post by trevordevore » Fri Apr 10, 2009 4:40 pm

With regards to the dg prefix on properties, I think here we must agree to disagree
Oh I don't think we disagree at all Jeff. I would LOVE to have english like syntax for the data grid. The problem is the engine doesn't allow a developer to define their own syntax yet and I imagine that adding support for that isn't trivial. Plus the engine will throw an error if you use ANY property that is already associated with a Revolution control.

What the above means is that you can't currently do this:

Code: Select all

set the text of group "Data Grid"
And while I could do this currently:

Code: Select all

set the data of group "Data Grid"
the code would suddenly break if Revolution added a "data" property to any control. Plus you would end up with some properties that read like "data" and others that read like "dgText" which wouldn't be ideal.
What happens if I delete this accidentally or return something different?
You would change the behavior of the data grid :-) There are only a few properties like dgLine or dgDataRecord and they all have the dg prefix. Having the dg prefix helps keep the names from conflicting with the developers own custom props though you are right, it isn't perfect.
Trevor DeVore
ScreenSteps - https://www.screensteps.com

LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder

Post Reply