Re: Table inspector from 4W

2008-10-15 Thread -= JB =-


On Oct 14, 2008, at 7:43 PM, Richard Gaskin wrote:



But independent column alignment is so very central to so much of  
what so many people want to build in Rev, and have wanted for so  
long, that I believe we're at a point where it can be reasonably  
said to be expected in the engine.  Much of what people need to  
display are numbers.


It's not just the 261 votes for that request that matter.  Those of  
us using the product now are a small number compared to those we  
need to see using it five years from now.  It's that much-larger  
audience of newcomers who will need it most, so they can just drop  
it in and move on to more interesting things like learning arcane  
SQL syntax, and along the way gain the feeling that they couldn't  
possibly use anything else because anything else would be too much  
work.


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com


I was tired and went to sleep for awhile.  I agree about the  
independent column
alignment.  You would always have to justify a whole column instead  
of 1 item.
And every time you resized the column it would need to justify it the  
column again
which would lead to big problems.  But it could be used in special  
cases where
the programmer does not want the user to be allowed to resize coiumns  
or the
rows are limited.  Another quick solution might be justify only what  
is visible on
screen and a little bit past or just use a paging system instead of  
scrolling.


But some of the other options would work real good for a lot of  
people and the
whole concept of making each item become as many different buttons as  
you
want will work too.  These things could open the doors to fields in  
new ways.


It needs to all be done by the Rev team with preferences that can be  
turned on
and off like other field preferences but it shows what Rev needs for  
the next

Revolution in programming and many parts can be worked in pretty easy.

-=JB=-
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread Richard Gaskin

Josep M Yepes wrote:
 Somebody know where can try this Inspector Palette that appear in the
 jpg? Or many info about this?
 I read this in the improve-revolution list some days ago...

 For example, a lot of my stuff lately requires display of data in
 lists in which I need an iTunes-quality display, with resizable
 columns that support sorting, etc.:
 http://fourthworldlabs.com/table.jpg

Thank you for your interest, Josep.

The library itself is functional and being used in a couple products, 
but the delay in making it available for others is that it has no 
documentation at this point.


When I've asked here previously for those interested in the library to 
write me I got a few enthusiastic responses, but admittedly only a few. 
 Given the amount of work my clients are asking of me (we're in the 
middle of major upgrades to most of the products I manage, with two new 
products also in development), documenting lib4WTable has taken a back seat.


I can try to coerce some time to put together even modest documentation 
in the next week or so.  No promises -- I get change orders coming in 
for our work from clients with enough frequency that it isn't possible 
to make firm commitments on things like this, but I'll see what I can do...


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread Bob Sneidar

Hi Richard.

I wonder what the price would be that you would charge to contract the  
work needed to document lib4WTable? If you could get enough of a  
commitment from other Revolution developers, I would certainly be  
willing to contribute just so we can have a working table model. But  
if it is more a problem of time then of course, that wouldn't help  
matters.


Bob Sneidar
IT Manager
Logos Management
Calvary Chapel CM

On Oct 14, 2008, at 11:15 AM, Richard Gaskin wrote:


Josep M Yepes wrote:

Somebody know where can try this Inspector Palette that appear in the
jpg? Or many info about this?
I read this in the improve-revolution list some days ago...

For example, a lot of my stuff lately requires display of data in
lists in which I need an iTunes-quality display, with resizable
columns that support sorting, etc.:
http://fourthworldlabs.com/table.jpg


Thank you for your interest, Josep.

The library itself is functional and being used in a couple products,
but the delay in making it available for others is that it has no
documentation at this point.

When I've asked here previously for those interested in the library to
write me I got a few enthusiastic responses, but admittedly only a  
few.

 Given the amount of work my clients are asking of me (we're in the
middle of major upgrades to most of the products I manage, with two  
new
products also in development), documenting lib4WTable has taken a  
back seat.


I can try to coerce some time to put together even modest  
documentation

in the next week or so.  No promises -- I get change orders coming in
for our work from clients with enough frequency that it isn't possible
to make firm commitments on things like this, but I'll see what I  
can do...


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread Richard Gaskin

Bob Sneidar

 On Oct 14, 2008, at 11:15 AM, Richard Gaskin wrote:
 http://fourthworldlabs.com/table.jpg

 The library itself is functional and being used in a couple products,
 but the delay in making it available for others is that it has no
 documentation at this point.

 When I've asked here previously for those interested in the library to
 write me I got a few enthusiastic responses, but admittedly only a
 few.  Given the amount of work my clients are asking of me (we're
 in the middle of major upgrades to most of the products I manage,
 with two new products also in development), documenting lib4WTable
 has taken a back seat.

 I can try to coerce some time to put together even modest
 documentation in the next week or so.  No promises -- I get change
 orders coming in for our work from clients with enough frequency
 that it isn't possible to make firm commitments on things like this,
 but I'll see what I can do...

 I wonder what the price would be that you would charge to contract the
 work needed to document lib4WTable? If you could get enough of a
 commitment from other Revolution developers, I would certainly be
 willing to contribute just so we can have a working table model. But
 if it is more a problem of time then of course, that wouldn't help
 matters.

One challenge here is to make sure we're all talking about the same type 
of table.  There are at least three kinds, as outlined earlier:

http://lists.runrev.com/pipermail/use-revolution/2008-April/109978.html

Of those, mine is the second kind, a list selector.  It's useful for 
databases, but does not attempt to provide the very different 
functionality of a spreadsheet or other types of grids.


In fact, at this time it doesn't even provide in-cell editing, though if 
I need that somewhere down the road I may add it.  Right now my UIs are 
very heavy in master-detail layouts, so in-cell editing just isn't 
something I need (and find myself frustrated with when iTunes insists on 
allowing it when I just want to double-click something).


What it does provide is a convenient way to have column headers at the 
top which:


- can be resized (or fixed; that's an option)

- can optionally support horizontal scrolling (useful for having more 
columns than can fit on screen)


- clicking on a column header sorts the data by that column, with the 
selection retained after the sort


- the sort column has a sort indicator arrow, and like iTunes the sort 
indicator remains at the clipping bounds of the group, so as you scroll 
for example the sort indicator stays in view until the column is 
completely offscreen (it's a subtle touch, but I rather like it g)



It's in two parts:  the object itself is a group which uses a standard 
Rev field for display and buttons and other stuff for the header, all 
bound up in a group for convenient manipulation.  Most of the code is in 
a library, so there's very little code redundancy if you use multiple 
groups (and it lets me fix/enhance it easily without mucking with the 
groups).


It's pretty much all property-driven, so you can put data into it, 
toggle its risizing and scrolling behaviors, etc., with simple property 
settings.


The resizing of the headers, while tricky with horizontal scrolling, 
isn't magic.  I believe lib4WTable can be a big time-saver over making a 
one-off from scratch, but because it uses Rev's field to display the 
text is has the same limits (on the upside that means it can store up to 
4GB; on the downside it means no independent column alignment at this time).


It serves my needs for list display well, and if it would suffice for 
others I'll give some thought to your question.


That said, at this stage it's not like I can just drop my commitments if 
we can find a way to bring in a larger hourly sum for lib4WTable.  But 
it would help encourage me to reprioritize it a little higher on my 
to-do list of free time activities to know that it'll be worth doing.


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread -= JB =-


On Oct 14, 2008, at 12:58 PM, Richard Gaskin wrote:

One challenge here is to make sure we're all talking about the same  
type of table.  There are at least three kinds, as outlined earlier:
http://lists.runrev.com/pipermail/use-revolution/2008-April/ 
109978.html


Of those, mine is the second kind, a list selector.  It's useful  
for databases, but does not attempt to provide the very different  
functionality of a spreadsheet or other types of grids.


In fact, at this time it doesn't even provide in-cell editing,  
though if I need that somewhere down the road I may add it.  Right  
now my UIs are very heavy in master-detail layouts, so in-cell  
editing just isn't something I need (and find myself frustrated  
with when iTunes insists on allowing it when I just want to double- 
click something).


What it does provide is a convenient way to have column headers at  
the top which:


- can be resized (or fixed; that's an option)

- can optionally support horizontal scrolling (useful for having  
more columns than can fit on screen)


- clicking on a column header sorts the data by that column, with  
the selection retained after the sort


- the sort column has a sort indicator arrow, and like iTunes the  
sort indicator remains at the clipping bounds of the group, so as  
you scroll for example the sort indicator stays in view until the  
column is completely offscreen (it's a subtle touch, but I rather  
like it g)



It's in two parts:  the object itself is a group which uses a  
standard Rev field for display and buttons and other stuff for the  
header, all bound up in a group for convenient manipulation.  Most  
of the code is in a library, so there's very little code redundancy  
if you use multiple groups (and it lets me fix/enhance it easily  
without mucking with the groups).


It's pretty much all property-driven, so you can put data into it,  
toggle its risizing and scrolling behaviors, etc., with simple  
property settings.


The resizing of the headers, while tricky with horizontal  
scrolling, isn't magic.  I believe lib4WTable can be a big time- 
saver over making a one-off from scratch, but because it uses Rev's  
field to display the text is has the same limits (on the upside  
that means it can store up to 4GB; on the downside it means no  
independent column alignment at this time).


It serves my needs for list display well, and if it would suffice  
for others I'll give some thought to your question.


That said, at this stage it's not like I can just drop my  
commitments if we can find a way to bring in a larger hourly sum  
for lib4WTable.  But it would help encourage me to reprioritize it  
a little higher on my to-do list of free time activities to know  
that it'll be worth doing.


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution




And then my Dynamic Table Field will allow you to edit each item,  
copy and
paste to each item and turn each item into as many different buttons  
as you

want.

Why doesn't the Rev team take some of these examples and build a  
flexible field
that everyone can use.  I have heard many people mention they want to  
have the
fields improved so it is obvious it would be wise economically to  
provide both new

and existing Rev customers what they want.

-=JB=-
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread J. Landman Gay

-= JB =- wrote:

Why doesn't the Rev team take some of these examples and build a 
flexible field
that everyone can use.  I have heard many people mention they want to 
have the
fields improved so it is obvious it would be wise economically to 
provide both new

and existing Rev customers what they want.


They know that. :)

--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread -= JB =-

On Oct 14, 2008, at 2:19 PM, J. Landman Gay wrote:


-= JB =- wrote:

Why doesn't the Rev team take some of these examples and build a  
flexible field
that everyone can use.  I have heard many people mention they want  
to have the
fields improved so it is obvious it would be wise economically to  
provide both new

and existing Rev customers what they want.


They know that. :)

--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___


So does that mean Richard would be wasting his time improving
his field because the Rev team are going to incorporate all of the
things he and others have already done.  They could easily add
the ability to for the end user to resize the field too.

Or does it simply mean, They know that.

Because if they have intentions of providing an exciting new field
with all of the extras I am sure Richard would be happy to work on
something that is not going to end up duplicating something that
will be a standard field for all Rev users integrated into Rev.

-=JB=-
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread Stephen Barncard
I'd rather have the rev team work on a new table control and a 
revised text field.


On OWhy doesn't the Rev team take some of these examples and build a 
flexible field

that everyone can use.  I have heard many people mention they want to have the
fields improved so it is obvious it would be wise economically to 
provide both new

and existing Rev customers what they want.

-=JB=-
___


--


stephen barncard
s a n  f r a n c i s c o
- - -  - - - - - - - - -



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread Bob Sneidar
WHOOPS! I have started another firestorm methinks. I have been  
informed that a table object of the nature you speak of IS a high  
priority to Runrev, but incorporating it is a huge thing. I do not  
think most people realize what a difficult thing table management is.  
Each cell is like it's own field. But then horizontal groups of fields  
can be controlled together as in changing the column width or changing  
the column formatting. And then rows are groups as well!


So do you need to be able to select rows/columns and do operations on  
them? How about font control? Does each cell get it's own formatting?  
Will you need discontinuous selections? How many will you allow?  
Endless? Will the data be stored in memory or use disk caching? Will  
you allow direct access to database queries to show up? Will you be  
able to lock/hide cells/rows/columns? Change the background/foreground  
colors of each cell or groups of cells?


For each of these operations there needs to be all new scripting  
commands. It's a HUGE undertaking. That is why I keep saying I would  
pay good money for a decent table object. It's probably one of the  
hardest things to implement in any user interface. I would rather have  
Runrev get it right out of the box then to be given a simplistic table  
object that does half of what I need, and then have to hope and pray  
they improve it in a reasonable time.


Bob Sneidar
IT Manager
Logos Management
Calvary Chapel CM

On Oct 14, 2008, at 2:30 PM, -= JB =- wrote:


So does that mean Richard would be wasting his time improving
his field because the Rev team are going to incorporate all of the
things he and others have already done.  They could easily add
the ability to for the end user to resize the field too.

Or does it simply mean, They know that.

Because if they have intentions of providing an exciting new field
with all of the extras I am sure Richard would be happy to work on
something that is not going to end up duplicating something that
will be a standard field for all Rev users integrated into Rev.

-=JB=-
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread -= JB =-


On Oct 14, 2008, at 2:54 PM, Bob Sneidar wrote:

WHOOPS! I have started another firestorm methinks. I have been  
informed that a table object of the nature you speak of IS a high  
priority to Runrev, but incorporating it is a huge thing. I do not  
think most people realize what a difficult thing table management  
is. Each cell is like it's own field. But then horizontal groups of  
fields can be controlled together as in changing the column width  
or changing the column formatting. And then rows are groups as well!


So do you need to be able to select rows/columns and do operations  
on them? How about font control? Does each cell get it's own  
formatting? Will you need discontinuous selections? How many will  
you allow? Endless? Will the data be stored in memory or use disk  
caching? Will you allow direct access to database queries to show  
up? Will you be able to lock/hide cells/rows/columns? Change the  
background/foreground colors of each cell or groups of cells?


For each of these operations there needs to be all new scripting  
commands. It's a HUGE undertaking. That is why I keep saying I  
would pay good money for a decent table object. It's probably one  
of the hardest things to implement in any user interface. I would  
rather have Runrev get it right out of the box then to be given a  
simplistic table object that does half of what I need, and then  
have to hope and pray they improve it in a reasonable time.


Bob Sneidar
IT Manager
Logos Management
Calvary Chapel CM


Each cell can already be controlled separately plus have its own font  
 style.  The columns
can already be resized but the rows still need to be able to be  
resized.  The data can be
stored how they are storing it now and if needed changed in the  
future.  There are already
examples that show how to resize and move fields.  Columns can  
automatically be resized
too.  Each cell can easily become as many separate  buttons as the  
programmers wants.
Searching and sorting can easily be incorporated.  Locking text is  
already a standard too.


Many things can be done very fast  because it is already being done.   
Integrating it all can
not be that hard unless they are trying to rewrite it in a different  
language and make it do

what is already being done with transcript.

After they release a sophisticated flexible table field users can  
make suggestions for

more features.

If it is too hard for them then Richard should continue improving his  
field.  If they have
intentions of changing it soon they should tell him so he won't waste  
his time.  He gives
a lot of his time already and considering the amount of time he has  
given they owe it to

him to not treat him like a mushroom and keep him in the dark.

-=JB=-
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread Richard Gaskin

-= JB =- wrote:
 Each cell can already be controlled separately plus have its own font
  style.  The columns can already be resized but the rows still
 need to be able to be resized.  The data can be stored how they are
 storing it now and if needed changed in the future.  There are
 already examples that show how to resize and move fields.  Columns
 can automatically be resized too.  Each cell can easily become as
 many separate  buttons as the programmers wants.
 Searching and sorting can easily be incorporated.  Locking text is
 already a standard too.

 Many things can be done very fast because it is already being done.

Where?


 After they release a sophisticated flexible table field users can
 make suggestions for more features.

 If it is too hard for them then Richard should continue improving his
 field.  If they have intentions of changing it soon they should tell
 him so he won't waste his time.  He gives a lot of his time already
 and considering the amount of time he has given they owe it to
 him to not treat him like a mushroom and keep him in the dark.

I appreciate the kind words.  Actually, before I started down this road 
I did check in with Kevin, and he told me it would be at least a year 
before RunRev provided any sort of header controls such as I was making. 
 That was more than a year ago, so the time spent on my little gadget 
has been useful.


If it were up to me, I would prioritize enhancements related to this 
with these two leading the pack because they're relatively simple and 
are oh so needed:


1. Independently resizable columns

2. Hidden columns

Those two would provide a significant step forward for most database 
work people are doing right now.  I would prioritize them above all 
else, esp. ahead of things I've heard very few ask for, like 
finely-tunable gradients.


Once those are in place, I would move forward with:

3. Decimal alignment in columns

4. Built-in header controls

5. Built-in option for in-cell editing

6. Built-in alternating line backgrounds

7. Update the threeDHilite for a rounded, more modern appearance

8. Allow multi-line cells

9. Allow controls in cells

These, coupled with the features in the current field object, that would 
suffice most of what people would need for list selectors.


Once the list selector is completely done, only then would I consider 
making a spreadsheet-style grid control.  Spreadsheet grids are very 
different from lists, much more complex and for a much smaller range of 
uses.


In fact, given the cost-to-benefit ratio of spreadsheet grids, I might 
go a completely different route to solving that, by not solving it at all:


Instead, I'd make an API for externally-defined controls, and worth with 
third parties to use that API to make widgets for vertical needs like 
spreadsheets, calendars, and just about anything else they can dream up.


Think altBrowser, but tightly coupled with the engine's rendering and 
messaging internals.


--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread -= JB =-


On Oct 14, 2008, at 4:17 PM, Richard Gaskin wrote:


-= JB =- wrote:
 Each cell can already be controlled separately plus have its own  
font

  style.  The columns can already be resized but the rows still
 need to be able to be resized.  The data can be stored how they are
 storing it now and if needed changed in the future.  There are
 already examples that show how to resize and move fields.  Columns
 can automatically be resized too.  Each cell can easily become as
 many separate  buttons as the programmers wants.
 Searching and sorting can easily be incorporated.  Locking text is
 already a standard too.

 Many things can be done very fast because it is already being done.

Where?


You say, Where?  Do you mean each thing I mentioned?  Please be
more specific so I can provide you a detailed answer.  Which item do
you want to know how to do?

-=JB=-
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread Richard Gaskin

-= JB =- wrote:

On Oct 14, 2008, at 4:17 PM, Richard Gaskin wrote:


-= JB =- wrote:
 Each cell can already be controlled separately plus have its own  
font

  style.  The columns can already be resized but the rows still
 need to be able to be resized.  The data can be stored how they are
 storing it now and if needed changed in the future.  There are
 already examples that show how to resize and move fields.  Columns
 can automatically be resized too.  Each cell can easily become as
 many separate  buttons as the programmers wants.
 Searching and sorting can easily be incorporated.  Locking text is
 already a standard too.

 Many things can be done very fast because it is already being done.

Where?


You say, Where?  Do you mean each thing I mentioned?  Please be
more specific so I can provide you a detailed answer.  Which item do
you want to know how to do?



I had the impression the above described a multi-platform control either 
made in Transcript or which could be easily integrated into the engine 
by the RunRev team.


If not, what does it describe?

--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread -= JB =-

On Oct 14, 2008, at 4:43 PM, Richard Gaskin wrote:


-= JB =- wrote:

On Oct 14, 2008, at 4:17 PM, Richard Gaskin wrote:

-= JB =- wrote:
 Each cell can already be controlled separately plus have its  
own  font

  style.  The columns can already be resized but the rows still
 need to be able to be resized.  The data can be stored how they  
are

 storing it now and if needed changed in the future.  There are
 already examples that show how to resize and move fields.  Columns
 can automatically be resized too.  Each cell can easily become as
 many separate  buttons as the programmers wants.
 Searching and sorting can easily be incorporated.  Locking text is
 already a standard too.

 Many things can be done very fast because it is already being  
done.


Where?

You say, Where?  Do you mean each thing I mentioned?  Please be
more specific so I can provide you a detailed answer.  Which item do
you want to know how to do?



I had the impression the above described a multi-platform control  
either made in Transcript or which could be easily integrated into  
the engine by the RunRev team.


If not, what does it describe?

--
 Richard Gaskin
 Fourth World Media Corporation


A few things like moving the fields were done in examples I have seen.

But if you want to do most of the other things it is done in my stack  
that

is named Dynamic Table Field.  It is in Rev online in the programming
section or you can look under the user name sundown.

If you have seen it and still don't know how to do the things I  
mentioned

please ask me.  When you look at the code you will see I even used a
piece of code you gave me when I asked a question on this list.

Let me know what feature you can't see readily and I will explain how
to do it and show you which part of the code does it.

As far as having each item be a different font and style it can actually
have each character in each item be a different font and style and it
can be done by using the paste option.

If the questions need to use more text than allowed on the list you can
contact me off list.

-=JB=-
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread J. Landman Gay

-= JB =- wrote:

Many things can be done very fast  because it is already being done.  
Integrating it all can
not be that hard unless they are trying to rewrite it in a different 
language and make it do

what is already being done with transcript.


Yup, that's the deal. The current table field in Rev's property 
inspector is just a regular field with some scripts in it. The 
functionality is faked. It's a sophisticated effort but is saddled, by 
its nature, with limitations.


What others are talking about is an honest to goodness table object 
implemented in the engine. Writing a new object for three operating 
systems using a low-level language is, as you mentioned, a huge 
undertaking. But if RR wants to have a real table, then that's what 
they'd need to do.


--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread Richard Gaskin

-= JB =- wrote:

 A few things like moving the fields were done in examples I have seen.

 But if you want to do most of the other things it is done in my stack
 that is named Dynamic Table Field.  It is in Rev online in the
 programming section or you can look under the user name sundown.

Got it - thanks.

 If you have seen it and still don't know how to do the things I
 mentioned please ask me.  When you look at the code you will see I
 even used a piece of code you gave me when I asked a question on
 this list.

:)  Small world.

 Let me know what feature you can't see readily and I will explain how
 to do it and show you which part of the code does it.

 As far as having each item be a different font and style it can
 actually have each character in each item be a different font and
 style and it can be done by using the paste option.

I think I had misunderstood the description in the earlier post.  For 
example:


Each cell can already be controlled separately plus have its
own font style.

True, as with any Rev chunk.  I was hoping for the holy grail of 
independent column alignment.  I've used multiple fields for that in the 
past, but getting the selection working well and keep things in synch is 
just more work than it needs to be, and suffers from poor performance.


Also:

   The columns can already be resized but the rows still
   need to be able to be resized.

In script one can set a field's tabstops, but in the Dynamic Table Field 
is there a way to resize them interactively with the mouse?


This one sounds intriguing:

  Each cell can easily become as many separate  buttons as the
  programmers wants.

What does that mean?


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread -= JB =-

On Oct 14, 2008, at 5:06 PM, J. Landman Gay wrote:


-= JB =- wrote:

Many things can be done very fast  because it is already being  
done.  Integrating it all can
not be that hard unless they are trying to rewrite it in a  
different language and make it do

what is already being done with transcript.


Yup, that's the deal. The current table field in Rev's property  
inspector is just a regular field with some scripts in it. The  
functionality is faked. It's a sophisticated effort but is saddled,  
by its nature, with limitations.


What others are talking about is an honest to goodness table object  
implemented in the engine. Writing a new object for three operating  
systems using a low-level language is, as you mentioned, a huge  
undertaking. But if RR wants to have a real table, then that's what  
they'd need to do.


--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com


It seems to me that with a small amount of team work the current  
table field

can be improved by leaps and bounds and then they can rewrite it in the
future if needed and slowly implement different features.

-=JB=-
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread -= JB =-

On Oct 14, 2008, at 5:15 PM, Richard Gaskin wrote:


-= JB =- wrote:

 A few things like moving the fields were done in examples I have  
seen.


 But if you want to do most of the other things it is done in my  
stack

 that is named Dynamic Table Field.  It is in Rev online in the
 programming section or you can look under the user name sundown.

Got it - thanks.

 If you have seen it and still don't know how to do the things I
 mentioned please ask me.  When you look at the code you will see I
 even used a piece of code you gave me when I asked a question on
 this list.

:)  Small world.

 Let me know what feature you can't see readily and I will explain  
how

 to do it and show you which part of the code does it.

 As far as having each item be a different font and style it can
 actually have each character in each item be a different font and
 style and it can be done by using the paste option.

I think I had misunderstood the description in the earlier post.   
For example:


Each cell can already be controlled separately plus have its
own font style.

True, as with any Rev chunk.  I was hoping for the holy grail of  
independent column alignment.  I've used multiple fields for that  
in the past, but getting the selection working well and keep things  
in synch is just more work than it needs to be, and suffers from  
poor performance.


Also:

   The columns can already be resized but the rows still
   need to be able to be resized.

In script one can set a field's tabstops, but in the Dynamic Table  
Field is there a way to resize them interactively with the mouse?


This one sounds intriguing:

  Each cell can easily become as many separate  buttons as the
  programmers wants.

What does that mean?


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com


I am not sure what you mean by each column having independent alignment.

To resize a single column you need to click to the left of a divider  
line and keep
the mouse held down.  The cursor will change to a hand, move the hand  
with
the mouse held down and after you release the cursor the column  
divider will

move to where the hand was.  This can be improved by using mousewithin 
changing the cursor to one like is used when you resize the dictionary.

The buttons idea is simple and staring you in the face.  You can see  
that I have
already made each item 3 different buttons.  Button 1 provides you  
the line and
item number along with the item clicked.  Button 2 allows you to  
click on an item
and it will copy that item and place it in the field above the copy  
button.  Button 3
allows you to paste the styled text in any item you click on.  This  
can be rewritten
to make it a little easier to provide options and the options are  
limitless.  You can
have it automatically do anything instead of one of the three options  
I provided.
They are not physical buttons which is even better they just allow  
each cell to

do as many different things you want when it is clicked.

-=JB=-
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread -= JB =-


On Oct 14, 2008, at 5:15 PM, Richard Gaskin wrote:


True, as with any Rev chunk.  I was hoping for the holy grail of  
independent column alignment.  I've used multiple fields for that  
in the past, but getting the selection working well and keep things  
in synch is just more work than it needs to be, and suffers from  
poor performance.


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com


I think I know what you mean by independent column alignment.  Are  
you wanting
to have each column use Left Center or RIght justification?  If so I  
bet that can be
done pretty easy and you could have each cell or each column  
justified.  It would
take a little bit of math to add a character in front of the item or  
column of items to

properly align the text Left Center or Right.  Not a big deal really.

-=JB=-
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread -= JB =-

On Oct 14, 2008, at 5:15 PM, Richard Gaskin wrote:


-= JB =- wrote:

 A few things like moving the fields were done in examples I have  
seen.


 But if you want to do most of the other things it is done in my  
stack

 that is named Dynamic Table Field.  It is in Rev online in the
 programming section or you can look under the user name sundown.

Got it - thanks.

--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com


One thing I should point out is a bug I found the other day and  
haven't fixed

yet but am pretty sure what the problem is.  When you use the option or
command keys to add an item to a cell in a empty column some of the
features don't work on that item any more like resizing the column.   
This

appears to be caused by the tab stops are not automatically changed to
account for the new column and it just needs the tab stops calculated
after the item in a new column is first entered.

-=JB=-
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread Richard Gaskin

-= JB =- wrote:
 I think I know what you mean by independent column alignment.
 Are you wanting to have each column use Left Center or RIght
 justification?

Yep - probably the one feature most developers here would prioritize 
above all else, so central to information displays as it is.



 If so I bet that can be done pretty easy and you could have each
 cell or each column justified.  It would take a little bit of math
 to add a character in front of the item or column of items to
 properly align the text Left Center or Right.  Not a big deal really.

Try it on a field with a couple hundred columns and a few thousand rows 
and you'll see where this goes pretty quickly.


Dropping that much data into a Rev field as it is today is lightning 
fast - faster to display and much smoother to scroll than even Excel or 
Word.


But if you had to walk through each item of each line to calculate the 
formattedWidth, and hope that you could obtain a correct formattedWidth 
for the preceding padding spaces needed to have it line up, with the 
engine as it currently is it's very slow.


And with anything other than monospaced fonts very close to impossible 
to get truly good alignment.  The space character is more than one pixel 
wide so it requires settling for approximation, which ultimately means 
some items will be a pixel or two off, resulting in a ragged right edge.


With a monospaced font it's possible to get adequate alignment, but the 
performance issue remains.  And with the customary application fonts on 
every supported platform being non-monospaced, whose users would be 
happy being limited to Courier or Monaco?  At a minimum, to deliver 
professional work we need Lucida Grande on OS X and Tregoe on Windows 
(though it does't matter on Linux because there is no single standard g).


As much as I appreciate your ambition, I believe this is a task best 
suited for the engine.


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread -= JB =-


On Oct 14, 2008, at 6:25 PM, Richard Gaskin wrote:


-= JB =- wrote:
 I think I know what you mean by independent column alignment.
 Are you wanting to have each column use Left Center or RIght
 justification?

Yep - probably the one feature most developers here would  
prioritize above all else, so central to information displays as it  
is.



 If so I bet that can be done pretty easy and you could have each
 cell or each column justified.  It would take a little bit of math
 to add a character in front of the item or column of items to
 properly align the text Left Center or Right.  Not a big deal  
really.


Try it on a field with a couple hundred columns and a few thousand  
rows and you'll see where this goes pretty quickly.


Dropping that much data into a Rev field as it is today is  
lightning fast - faster to display and much smoother to scroll than  
even Excel or Word.


But if you had to walk through each item of each line to calculate  
the formattedWidth, and hope that you could obtain a correct  
formattedWidth for the preceding padding spaces needed to have it  
line up, with the engine as it currently is it's very slow.


And with anything other than monospaced fonts very close to  
impossible to get truly good alignment.  The space character is  
more than one pixel wide so it requires settling for approximation,  
which ultimately means some items will be a pixel or two off,  
resulting in a ragged right edge.


With a monospaced font it's possible to get adequate alignment, but  
the performance issue remains.  And with the customary application  
fonts on every supported platform being non-monospaced, whose users  
would be happy being limited to Courier or Monaco?  At a minimum,  
to deliver professional work we need Lucida Grande on OS X and  
Tregoe on Windows (though it does't matter on Linux because there  
is no single standard g).


As much as I appreciate your ambition, I believe this is a task  
best suited for the engine.


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com


I am sure the Rev team can speed things up in time.  But many  
features available

are much better than nothing at all.

As for the proper spacing when I was using a demo of Rev over a year  
ago I asked
about adding a glyph for justification.  Someone suggested make an  
invisible image
for a glyph which would be 1 point and you could then enter the  
amount needed.


Things can be improved by the Rev team but many things can be used  
now.  If it gets
so large it is too slow you will have to wait for those options to be  
improved.


-=JB=-
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread -= JB =-


On Oct 14, 2008, at 6:25 PM, Richard Gaskin wrote:


-= JB =- wrote:
 I think I know what you mean by independent column alignment.
 Are you wanting to have each column use Left Center or RIght
 justification?

Yep - probably the one feature most developers here would  
prioritize above all else, so central to information displays as it  
is.



 If so I bet that can be done pretty easy and you could have each
 cell or each column justified.  It would take a little bit of math
 to add a character in front of the item or column of items to
 properly align the text Left Center or Right.  Not a big deal  
really.


Try it on a field with a couple hundred columns and a few thousand  
rows and you'll see where this goes pretty quickly.


Dropping that much data into a Rev field as it is today is  
lightning fast - faster to display and much smoother to scroll than  
even Excel or Word.


But if you had to walk through each item of each line to calculate  
the formattedWidth, and hope that you could obtain a correct  
formattedWidth for the preceding padding spaces needed to have it  
line up, with the engine as it currently is it's very slow.


And with anything other than monospaced fonts very close to  
impossible to get truly good alignment.  The space character is  
more than one pixel wide so it requires settling for approximation,  
which ultimately means some items will be a pixel or two off,  
resulting in a ragged right edge.


With a monospaced font it's possible to get adequate alignment, but  
the performance issue remains.  And with the customary application  
fonts on every supported platform being non-monospaced, whose users  
would be happy being limited to Courier or Monaco?  At a minimum,  
to deliver professional work we need Lucida Grande on OS X and  
Tregoe on Windows (though it does't matter on Linux because there  
is no single standard g).


As much as I appreciate your ambition, I believe this is a task  
best suited for the engine.


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com


Another way to speed it up would do not have a few thousand rows.   
This could be
overcome by using a database and after so many rows were scrolled the  
database
would get the next hundred or so, whatever works.  I am not saying it  
is perfect but

if that is what you need it would be better than nothing.

-=JB=-
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread -= JB =-


On Oct 14, 2008, at 6:48 PM, -= JB =- wrote:



On Oct 14, 2008, at 6:25 PM, Richard Gaskin wrote:


-= JB =- wrote:
 I think I know what you mean by independent column alignment.
 Are you wanting to have each column use Left Center or RIght
 justification?

Yep - probably the one feature most developers here would  
prioritize above all else, so central to information displays as  
it is.



 If so I bet that can be done pretty easy and you could have each
 cell or each column justified.  It would take a little bit of math
 to add a character in front of the item or column of items to
 properly align the text Left Center or Right.  Not a big deal  
really.


Try it on a field with a couple hundred columns and a few thousand  
rows and you'll see where this goes pretty quickly.


Dropping that much data into a Rev field as it is today is  
lightning fast - faster to display and much smoother to scroll  
than even Excel or Word.


But if you had to walk through each item of each line to calculate  
the formattedWidth, and hope that you could obtain a correct  
formattedWidth for the preceding padding spaces needed to have it  
line up, with the engine as it currently is it's very slow.


And with anything other than monospaced fonts very close to  
impossible to get truly good alignment.  The space character is  
more than one pixel wide so it requires settling for  
approximation, which ultimately means some items will be a pixel  
or two off, resulting in a ragged right edge.


With a monospaced font it's possible to get adequate alignment,  
but the performance issue remains.  And with the customary  
application fonts on every supported platform being non- 
monospaced, whose users would be happy being limited to Courier or  
Monaco?  At a minimum, to deliver professional work we need Lucida  
Grande on OS X and Tregoe on Windows (though it does't matter on  
Linux because there is no single standard g).


As much as I appreciate your ambition, I believe this is a task  
best suited for the engine.


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com


Another way to speed it up would do not have a few thousand rows.   
This could be
overcome by using a database and after so many rows were scrolled  
the database
would get the next hundred or so, whatever works.  I am not saying  
it is perfect but

if that is what you need it would be better than nothing.

-=JB=-
___


If you only changed the justification for one column at a time the  
speed would

not be hampered by the number of columns since it would use the code you
provided to get one column at a time.

If you changed the justification of one item at a time your number of  
rows would

not change the speed either.

So the slow down would be how many rows of one column would justify at a
reasonable speed.  How often do you need to change the justification  
of the
whole column since it is being justified for each item according to  
the setting
for that column.  There would be some slow times but if you are not  
changing
the justification of a whole column very often you would end up with  
the look

you wanted and that look may not even need to be changed in some stacks.
Therefore you would only be changing one item at a time.

-=JB=-
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-14 Thread Richard Gaskin

-= JB =- wrote:

 I am sure the Rev team can speed things up in time.  But many
 features available are much better than nothing at all.

 As for the proper spacing when I was using a demo of Rev over a
 year ago I asked about adding a glyph for justification. Someone
 suggested make an invisible image for a glyph which would be 1
 point and you could then enter the amount needed.

 Things can be improved by the Rev team but many things can be used
 now.  If it gets so large it is too slow you will have to wait for
 those options to be improved.

 Another way to speed it up would do not have a few thousand rows.
 This could be overcome by using a database and after so many rows
 were scrolled the database would get the next hundred or so,
 whatever works.

Both of those are very clever workarounds, but they must be recognized 
for what they are.


The extra characters for the images, while aiding display, complicate 
data retrieval since they must be parsed out.


The buffered display of long lists can work in some cases, but it means 
either accepting a scrollbar whose thumb bears no relationship to the 
field contents, or using a separate scrollbar object and managing it 
yourself.


Sure, it's all doable, but a dozen lines here and a dozen lines there 
and pretty soon you have a rather complex subsystem on your hands -- a 
subsystem that doesn't add innovative features to one's app as much as 
simply compensate for not having basic ones.


For the relative few in the Rev community with the experience to pull 
off such a set of workarounds gracefully, our clients would rather we be 
working on bullet-point features.


And for newcomers, it's quite a lot to ask of them to figure all that out.

Things like this are a lot like chunk expressions:  you can parse text 
in any language, but I hate parsing text in any language that doesn't 
have chunk expressions.  It's so logical, so efficient, so very much the 
right way to handle that task.


Ideally everything in the Rev experience would be as compelling, at 
least the most commonly-used stuff.



That said, here you show yourself to be a man after my own heart:

 I am not saying it is perfect but if that is what you need it
 would be better than nothing.

Amen, brother.  I hope my nit-picking over this object doesn't appear 
arbitrary.  In general, I'm right with you on that, and often seek some 
way to get an immediate solution, however imperfect, to get the job done 
and move on to other things.


But there's a delicate balance in the ratio of time spent on a 
workaround relative to its quality and relative to the complexity it 
adds to one's code base.


If you absolutely need a independent column alignment, there are ways to 
do it (I'd probably favor multiple lists with a single list overlaid, 
but that also comes at a price of its own in parsing and reassembling data).


But the cost of doing it is high, the complexity it adds is relatively 
high, and the final result performs slower than even Java.


For highly specialized things that only one or a few people need (for 
example, a sonar dial widget for a Battleship game, or an orthogonal 
grid library for visual simulations), sometimes you just gotta roll up 
your sleeves and cut some code.  I'm okay with that.  Sometimes I even 
enjoy it. :)


But independent column alignment is so very central to so much of what 
so many people want to build in Rev, and have wanted for so long, that I 
believe we're at a point where it can be reasonably said to be expected 
in the engine.  Much of what people need to display are numbers.


It's not just the 261 votes for that request that matter.  Those of us 
using the product now are a small number compared to those we need to 
see using it five years from now.  It's that much-larger audience of 
newcomers who will need it most, so they can just drop it in and move on 
to more interesting things like learning arcane SQL syntax, and along 
the way gain the feeling that they couldn't possibly use anything else 
because anything else would be too much work.


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Table inspector from 4W

2008-10-11 Thread Josep M Yepes

Hi,

Somebody know where can try this Inspector Palette that appear in the  
jpg? Or many info about this?

I read this in the improve-revolution list some days ago...


For example, a lot of my stuff lately requires display of data in lists
in which I need an iTunes-quality display, with resizable columns that
support sorting, etc.:
http://fourthworldlabs.com/table.jpg

Cheers,
Josep M
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-11 Thread Bernard Devlin
Josep, I'm not sure if Richard Gaskin is licensing that table component yet
or not (www.fourthworld.com).  He had qualms a couple of years ago about it
not being ready, but that may have changed.

You could also look at Chipp's AltFldHeader.  I believe it is doing
something similar.  It is a deceptively simple approach to table fields, and
is configured somewhat differently to Richard's.  Hmm.. I just searched
Chipp's website (www.altuit.com), and couldn't find it.  Maybe he has
withdrawn it.  Hopefully, he'll see this and mention if it is still
available.

Bernard

On Sat, Oct 11, 2008 at 12:12 PM, Josep M Yepes [EMAIL PROTECTED] wrote:

 Hi,

 Somebody know where can try this Inspector Palette that appear in the jpg?
 Or many info about this?
 I read this in the improve-revolution list some days ago...


 For example, a lot of my stuff lately requires display of data in lists
 in which I need an iTunes-quality display, with resizable columns that
 support sorting, etc.:
 http://fourthworldlabs.com/table.jpg

 Cheers,
 Josep M
 ___
 use-revolution mailing list
 use-revolution@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-revolution

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Table inspector from 4W

2008-10-11 Thread Chipp Walters
altFldHeader is still with the other altPlugins at:
http://www.altuit.com/webs/altuit2/altPluginCover/About.htm

I really need to update that website so it's easier to navigate and find stuff.

I also released a new version of altXray-- beta. This one adds the
ability to show 'separator' comments in the handler list to better
organize scripts which have lots of handlers. Clicking the update
button on altXray should get you the latest version. Shift-click the
disk icon on altXray to see the instructions on how to use it.

best,
Chipp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution