how to delete row in the polygrid?

[lemodizon]

Hello everyone,

I'm trying to delete a row in the polygrid but it doesn't delete the row I want to delete. I don't know if the word dispatch is ok to use in the polygrid or can use the repeat?

Code: Select all

on mouseUp

 put the hilitedline of widget "pgDetails"  into theLine
   answer "The selected line var is : " & theLine
   dispatch "deleteline" to widget "pgDetails"  with theLine
   put the result into tDeleteresult
   
   if tDeleteresult is not empty 
   then 
      answer "There has been a problem deleting the line with message: "&tDeleteresult
   else
      answer "Line Deleted"
   
   end if
end mouseUp

what is the meaning of unhandled i just saw it see the pic below

[Klaus]

Hi lemodizon,

the new widgets have a sometime laughable syntax!?
To delete a line in a PolyGrid use:

Code: Select all

...
answer "The selected line var is : " & theLine
set the pgDeleteRow of widget "pgDetails" to theLine
...

Best

Klaus

[stam]

Yeah I was going to say exactly that... New widgets have odd syntax indeed.

You seem to be using the datagrid syntax, but polygrid is a completely different thing and has its own syntax. Always look up the dictionary...

You cannot dispatch "deleteLine" to a polygrid (or you can, but it will do nothing); instead, you set a property called pgDeleteRow to the line number(s) you want to delete.
It seems weird, but probably a byproduct of this being a widget rather than a group.

It is all in the dictionary mind you:

Example

Code: Select all

set the pgDeleteRow of widget "PolyGrid" to "5,8,45"

Description
Use the pgDeleteRow property to delete one or more lines from the PolyGrid. This property will always return an empty string.

[lemodizon]

Hi stam & klaus,

Thanks for the help.

[dunbarx]

This makes no sense to me at all. If a polygrid requires that a property of its lines be set to "delete", then what happens if one wants to put something back into that line? Do I assume you set that property back to "false", and THEN place the new data into the line?

Oh, wait, I see. I bet you set the pgDoNotDeleteRow to "true"?

Craig

[stam]

This makes no sense to me at all. If a polygrid requires that a property of its lines be set to "delete", then what happens if one wants to put something back into that line? Do I assume you set that property back to "false", and THEN place the new data into the line?

Oh, wait, I see. I bet you set the pgDoNotDeleteRow to "true"?

Craig

Hi Craig, you're not setting a property of any lines; this is a custom property of the widget and passing the line numbers as a parameter lets this be handled in its setProp handler. Weird indeed. But I've certainly used this kind of approach in other contexts like script widgets.

They use the same approach for adding data (and by they I suspect it's not LC but rather the developer they purchased this from... FerrusLogic?).
You set a property that triggers a setProp handler using the parameters provided.
You can look up the addData, addDataBefore and addDataAfter properties that insert data at the end of the grid, before or after a specified line respectively.

The most disturbing thing with the PG API is its requirement to set the pgInternalPointer to the line number you wish, where in my mind it should be a parameter... but not having this as a function limits the parameter to pass to 1 parameter and 'they' obviously felt that it would confuse people to add it as an array key

He's an example from the dictionary:

Code: Select all

-- Adds two new items to the content of the table after the row 5
local tDataToAdd
put "One" into tDataToAdd[1]["col 1"]
put "Two" into tDataToAdd[2]["col 1"]
set the pgInternalPointer of widget "PolyGrid" to 5 --> line of weirdness
set the addDataAfter of widget "PolyGrid" to tDataToAdd

Overall not a very LC-like API at all - but it is a good widget...

[dunbarx]

Thanks for that, Stam.

It still seems odd to me that a widget, of any kind, strays so far from "standard" LC thinking. Maybe there are performance benefits?

Anyway, can you tell me briefly what a polyGrid does that either a table field or a dataGrid does not? Does it lie in the middle of those two in terms of ease of use and power? I cannot imagine it being more powerful than a DG.

Craig

[dunbarx]

Klaus (and Stam or anyone)...

set the pgDeleteRow of widget "pgDetails" to theLine

I have never used a widget. But is it true that one can simply refer to a widget by name when setting a property that likely only makes sense to a certain type of widget?

You cannot dispatch "deleteLine" to a polygrid (or you can, but it will do nothing)

So LC would not throw an error if that line of code was placed, say, in a clock widget? I think LC should at least have some sort of an error message "Inappropriate for this type of widget".

One real departure from what I am used to is this. Wouldn't that line of code, as Stam mentioned, set a custom property? How could it not? That the property itself has no bearing on the widget itself, that is, that widget would never call on it, should make no difference at all.

Or is that in fact what happens, the property is set, but it does not matter, since the widget will ignore it. In that case, back to some sort of feedback...

Craig

[dunbarx]

Stam.

the developer they purchased this from... FerrusLogic?).

I had no idea (some?) widgets were not home grown. What other widgets come from Taco Bell?

Craig

[dunbarx]

So I just played around with a polyGrid. Nice looking, and I answered my own question, they are in between a table field and a DG; the widget API is very friendly. I will consider them the next time I need anything like it. I am less outraged now than a couple of hours ago, except for Taco Bell.

Craig

[stam]

I was going to answer sooner but due to a series of unfortunate and unforeseen events I find myself on call 26 out of 30 consecutive days, and I’m only 10 days in

I only presume they must have purchased these widgets. PolyGrid was announced on these forums my FerrusLogic some months before being sold by LC ; they then pulled it and it suddenly appeared in the summer megabundle some months later.

Similarly the button widget is pretty much a carbon copy of an existing opensource offering - but of course they may have just not paid that developer.
All widgets have very sparse documentation with wildly different naming conventions (for example the array data of polyGrid is referred to with pgData while the same for polyList is named dataContent).

PolyGrid, as I’m sure you discovered, offers a subset of features the extremely capable DataGrid offers but is faster and more portable in the sense you can just copy/paste between stacks freely, because it doesn’t have the DG’s drawback of using a behaviour substack - it’s completely encapsulated.

DG still offers a much larger feature set and has its role, especially if you want the “form” rather than the “table” version. PolyList again offers a different subset (more of a “form” style grid) but also a new feature: you can have columns of rows.
But other than that, the DG can do everything these two widgets offer and has the benefit of letting us lay out row and column prototypes using the standard IDE and can use any available widget.


I don’t think buying widgets and distributing them is a bad thing though. A thriving ecosystem does need independent widget builders and so on, And if LC purchased these then good on them for supporting indie developers. I would find this reassuring and pleasing.

But they could have done a much better job with documentation of these new widgets…