Re: arrays

> The "filter" command is one of those things that you can stare at for > a while, but it doesn't really click until you have a use for it. Then > whole new worlds open up. On major caveat on "filter" though, and that is that the closer to the left edge of a line the filter is acting on (or the l

Re: arrays

Tom- The "filter" command is one of those things that you can stare at for a while, but it doesn't really click until you have a use for it. Then whole new worlds open up. -- -Mark Wieder mwie...@ahsoftware.net ___ use-revolution mailing list use-rev

re: arrays

Thank you Sarah, Mark and the rest! I'm so basic sometimes. Filter? Duh! After all this time, I don't know the basics. With the filter scripting, I can winnow the data down into manageable chunks before I do anything, and there is no speed issue at all. I'm blazing through this data and who

Re: Arrays

Hi Tom, Assuming your data is in a variable called tData, and is structured like this: Elliot and Cooper Roads, sparrow Elliot and Cooper Roads, magpie Elliot and Cooper Roads, dove Elliot and Cooper Roads, owl Downing Street, sparrow this will give you a list of the birds in Elliot and Cooper R

Re: Arrays

Tom- Tuesday, May 19, 2009, 2:07:32 PM, Sarah wrote: > Just remember that you need to use * to indicate to the filter command > that you will accept lines with more than just "Elliot and Cooper > Roads". Yes, Sarah's right about this. I was assuming from the pseudodata that each entry started wi

Re: Arrays

On Wed, May 20, 2009 at 6:47 AM, Mark Wieder wrote: > Tom- > > Tuesday, May 19, 2009, 9:04:06 AM, you wrote: > >> If someone could show me how to do this, then I could employ it >> everywhere and my flat database would be screamin' fast and I would >> stay in Revolution. > > filter tVariable with

Re: Arrays

Tom- Tuesday, May 19, 2009, 9:04:06 AM, you wrote: > If someone could show me how to do this, then I could employ it > everywhere and my flat database would be screamin' fast and I would > stay in Revolution. filter tVariable with "Elliot and Cooper Roads*" -- -Mark Wieder mwie...@ahsoftware.

Re: Arrays

Tom Cole wrote: I have bird watching PLACES as one item. One is called Elliot and Cooper Roads. I've been to that street corner hundreds of times, and since I have seen over 8000 birds there, there are more than 8000 records. I can put all of the records for this street corner at the top of th

Re: Arrays

Hi Tom, maybe something like this will do: replace "Elliot and Cooper Roads" with "Elliot and Cooper Roads" && "[whatever needs to be paste]" & return in yourVariableWithData? Viktoras Tom Cole wrote: Sarah, Thanks. The sorts are MUCH faster when done in a variable. I'm not sure of the adva

Re: Arrays

Sarah, Thanks. The sorts are MUCH faster when done in a variable. I'm not sure of the advantage of storing data in a custom property, but it's nice to know about. I'm forgetting arrays because now I need do only one thing to be burning through the data. I have bird watching PLACES as one i

Re: Arrays instead of Sql

Tom, sort the data in variable instead of field using field only to display results, not for the data processing, or at least lock screen before sorting and then unlock screen. This will be much faster. When putting data into field again lock screen and unlock afterwards. This will prevent f

Re: Arrays instead of Sql

Tom, As Phil said, we get acceptable speed using Custom Properties - even on databases with 100,000+ records - usually served by a Mac Mini. Compliments to Richard Gaskin who originally suggested the approach. By the way: no SQL, no C, no extensions! Paul Looney On May 18, 2009, at 6:02 PM,

Re: Arrays instead of Sql

Sarah Reichelt wrote: On Tue, May 19, 2009 at 10:30 AM, Tom Cole wrote: I've heard that instead of using a backend like sql to manage a database, I could stay in Revolution and use arrays. I know nothing of arrays. I've written here before about a bird database I have. Several times. Forgiv

Re: Arrays instead of Sql

On Tue, May 19, 2009 at 10:30 AM, Tom Cole wrote: > I've heard that instead of using a backend like sql to manage a database, I > could stay in Revolution and use arrays. I know nothing of arrays. > > I've written here before about a bird database I have. Several times. > Forgive. > > I just have

Re: Arrays and Custom Props

You don't know Apple very well. It will be something like Y2. Bob Sneidar IT Manager Logos Management Calvary Chapel CM On Feb 17, 2009, at 6:06 PM, Kay C Lan wrote: Sounds like a full 12/12 warranty to me. 12" or 12 sec, whichever comes first ;-) Oh, and you sure it won't be OS Y ? ;-)

Re: Arrays and Custom Props

On Wed, Feb 18, 2009 at 9:41 AM, Richard Gaskin wrote: > See the Dictionary: > getResources > getResource > setResource > Which I have. Thanks again to this List, I don't think there would be any other way I'd ever have conceived as to why I'd ever look these up. > > Good for as long as Apple c

Re: Arrays and Custom Props

Kay C Lan wrote: On Tue, Feb 17, 2009 at 1:43 PM, Richard Gaskin wrote: So while these various different parts are technically in the same file, this is merely a clever trick of the legacy file system which still supports resource forks. As such, it's just one level of misdirection away from b

Re: Arrays and Custom Props

On Tue, Feb 17, 2009 at 1:43 PM, Richard Gaskin wrote: > > So while these various different parts are technically in the same file, > this is merely a clever trick of the legacy file system which still supports > resource forks. As such, it's just one level of misdirection away from > being more

Re: Arrays and Custom Props

Kay C Lan wrote: I then quit ScriptEditor and double clicked on my newly created App. It came up with a dialog with the number 1 and then self quit. I double clicked on it again and it said 2, etc etc. The Modification Time of the file changed with each running of the App. Does it have a resou

Re: Arrays and Custom Props

Kay C Lan wrote: On Tue, Feb 17, 2009 at 6:11 AM, Richard Gaskin wrote: At the risk of pulpifying this long-dead horse, for clarity's sake I don't believe it's the *executable• within an AppleScript applet bundle that is being modified. AFAIK that isn't possible in any UNIX-based system. I f

Re: Arrays and Custom Props

On Tue, Feb 17, 2009 at 6:11 AM, Richard Gaskin wrote: > > At the risk of pulpifying this long-dead horse, for clarity's sake I don't > believe it's the *executable• within an AppleScript applet bundle that is > being modified. AFAIK that isn't possible in any UNIX-based system. > I figured the

Re: Arrays and Custom Props

Thanks Mark that is probably the methodology I will use when the time comes. Bob Sneidar IT Manager Logos Management Calvary Chapel CM On Feb 16, 2009, at 2:10 PM, Mark Swindell wrote: The exception to the above is that if you make any change to an executable (a standalone), including addin

Re: Arrays and Custom Props

Stephen, You are correct, of course. I was over-simplifying. I completely agree with you that putting user data inside a stack inside a standalone is not a good idea. The most important point I was trying to make was, as Mark had said earlier, custom properties can persist. Paul Looney On Fe

Re: Arrays and Custom Props

Bob Sneidar wrote: Sorry all didn't make myself clear. The "oddity" was not that Mac apps are packages. The "oddity" is that the properties cannot be saved when you quit the app because they are (ostensibly) part of the executable. I believe that was the reason given for the fact that a revo

Re: Arrays and Custom Props

Bob, You're right, I'm not clear what you're saying. :) First off, I'm not one of the illuminati on this list by a long shot. But I do think I have a grasp of a couple of concepts, and I'll be corrected if I'm wrong. Properties are associated with objects. Objects come with a set of bu

Re: Arrays and Custom Props

Sorry all didn't make myself clear. The "oddity" was not that Mac apps are packages. The "oddity" is that the properties cannot be saved when you quit the app because they are (ostensibly) part of the executable. I believe that was the reason given for the fact that a revolution executable

Re: Arrays and Custom Props

Bob Sneidar wrote: Oh gotcha! So you are saying that the properties are something that is a part of the executable inside the package? How odd. The confusion stems from OS X lying to us: it tells us that an application is a file, when it's really a folder. :) The actual executable (the ru

Re: Arrays and Custom Props

Bob- Monday, February 16, 2009, 11:01:59 AM, you wrote: > Oh gotcha! So you are saying that the properties are something that is > a part of the executable inside the package? How odd. Not that odd if you think of the "package" as a folder. That's what it is and it's up to the OS to show it to y

Re: Arrays and Custom Props

Oh gotcha! So you are saying that the properties are something that is a part of the executable inside the package? How odd. Anyway, I don't want to belabor the point. The fact is, there are workarounds, and some with real benefits (such as default restoration) and such that will work nicel

Re: Arrays and Custom Props

Bob- Monday, February 16, 2009, 10:28:57 AM, you wrote: > BTW I tested the theory that an app cannot be modified while running. > This is not true. I opened TextEdit and while it was running I opened > the package contents and edited a plist file using PlistEditPro. I > changed one of the value

Re: Arrays and Custom Props

If this is another duplicate from me I apologise. My email keeps defaulting to the wrong account and I don't catch it in time. Bob Sneidar IT Manager Logos Management Calvary Chapel CM On Feb 13, 2009, at 4:24 PM, Robert Sneidar wrote: WHOA THERE TONTO! I thought the whole idea to properties

Re: Arrays and Custom Props

Thanks Mark! Just what the doctor ordered (again from you). I thought I remembered something like this. Since the app is mainly going to be used in house that will be perfect. Bob Sneidar IT Manager Logos Management Calvary Chapel CM On Feb 14, 2009, at 2:40 PM, Mark Swindell wrote: On Fe

Re: Arrays and Custom Props

> > Like with fields, you can not store user information in a custom property > in an application (or standalone). > This isn't quite right. On the mac, I can save data to a separate stack INSIDE of a standalone package with no problem. Not always the best place to put the data in some situations,

Re: Arrays and Custom Props

Bob Sneidar wrote: BTW I tested the theory that an app cannot be modified while running. This is not true. I opened TextEdit and while it was running I opened the package contents and edited a plist file using PlistEditPro. I changed one of the values and saved the plist successfully. You we

Re: Arrays and Custom Props

Hi Mark. Thanks. I do understand that properties are persistent so long as a standalone is running. I understand that Revolution standalones will not save the state of properties when you quit them. I was saying that Applescript standalones CAN and DO save the state of properties when the

Re: Arrays and Custom Props

Bob, Think of custom properties as fields - without some of the field overhead. Putting information in custom properties and retrieving it is much faster than using fields. And you can create and delete custom properties on the fly much more easily than with fields - with less code. Two fi

Re: Arrays and Custom Props

And persistent they are, if the stack file the custom properties are in is saved with a simple save command. A stack file can hold any number of custom properties. Even arrays, stacks and images can be turned into a custom property and restored. Persistence = a file somewhere!The file can be in a

Re: Arrays and Custom Props

WHOA THERE TONTO! I thought the whole idea to properties was persistence?? That means that I cannot save, for instance, the database settings a user entered? I have to create an external file for all of that? And so many card and object properties in my app DEPEND on persistence through run

Re: Arrays and Custom Props

Good stuff, Jim. Well thought out. Thanks for sharing it. Gregory On Sun, Feb 15, 2009, at 1:00 PM, use-revolution-requ...@lists.runrev.com wrote: Message: 9 Date: Sat, 14 Feb 2009 16:45:24 -0800 From: Jim Ault Subject: Re: Arrays and Custom Props --not trivial- agreed To: How

Re: Arrays and Custom Props --not trivial- agreed

>Jim Ault's good overview in response to this thread > shows that strategies for developing a working relationship with > custom props is not trivial. Agreed. Just as building a good set of database linked tables (schema) takes some planning, so do custom properties. Accessing database records is

Re: Arrays and Custom Props

Mark Swindell wrote: On Feb 14, 2009, at 1:18 PM, Robert Sneidar wrote: I thought after I sent the email, is there a runtime engine for rev that would allow stacks to run as documents? Yes, Revolution Player: http://www.runrev.com/downloads/all-downloads/revolution-player/ or Ken Ray's Stac

Re: Arrays and Custom Props

On Feb 14, 2009, at 1:18 PM, Robert Sneidar wrote: I thought after I sent the email, is there a runtime engine for rev that would allow stacks to run as documents? Yes, Revolution Player: http://www.runrev.com/downloads/all-downloads/revolution-player/ or Ken Ray's Stackrunner http://www.so

Re: Arrays and Custom Props

Robert- Saturday, February 14, 2009, 1:27:33 PM, you wrote: > I suppose where I was getting confused is that Applescript apps > properties are persistent. I just assumed rev apps pulled the same > kind of trick. Methinks you're still a bit confused about this. Custom. Properties. Are. Persis

Re: Arrays and Custom Props

I suppose where I was getting confused is that Applescript apps properties are persistent. I just assumed rev apps pulled the same kind of trick. Bob Sneidar IT Manager Calvary Chapel CM Sent from iPhone On Feb 14, 2009, at 8:45, Jim Ault wrote: I think people get a little confused when th

Re: Arrays and Custom Props

I thought after I sent the email, is there a runtime engine for rev that would allow stacks to run as documents? Bob Sneidar IT Manager Calvary Chapel CM Sent from iPhone On Feb 13, 2009, at 16:42, Richard Gaskin wrote: Bob Sneidar wrote: WHOA THERE TONTO! I thought the whole idea to pr

Re: Arrays and Custom Props

Well, Bernard and Scott, good to know I'm not alone. I've always been ambivalent about custom properties. I see their power and usefulness, but more often than not, I spare myself the mental strain of recalling what prop is stored where, what it is called, and how to display all of the o

Re: Arrays and Custom Props

I think people get a little confused when they think of Hypercard and how it always saved changes to the hard drive as they occurred. The key is that Hypercard stacks are like spreadsheets or word processing documents in that you needed the app Hypercard installed on your Mac, and it was free. Mo

Re: Arrays and Custom Props

Bob- Friday, February 13, 2009, 4:29:13 PM, you wrote: > Say it ain't so Sam! You might want to check out the section on Splash Screens in the scripting conference stack devoted to building standalones... http://support.runrev.com/scriptingconferences/ -- -Mark Wieder mwie...@ahsoftware.net

Re: Arrays and Custom Props

Bob Sneidar wrote: WHOA THERE TONTO! I thought the whole idea to properties was persistence?? That means that I cannot save, for instance, the database settings a user entered? I have to create an external file for all of that? And so many card and object properties in my app DEPEND on pe

Re: Arrays and Custom Props

WHOA THERE TONTO! I thought the whole idea to properties was persistence?? That means that I cannot save, for instance, the database settings a user entered? I have to create an external file for all of that? And so many card and object properties in my app DEPEND on persistence through run

Re: Arrays and Custom Props

Just a couple hints that might help you in the future.. I hope this can help someone understand a little more. I think of arrays as.. Arrays, like variables, evaporate on quitting, Custom properties, like button names, are stored in the stack file. (note: this is not true for compiled apps since

Re: Arrays and Custom Props

Recently, Bernard Devlin wrote: > I think I must have been particularly stupid at the time when I was learning > how to use arrays, and my confusion has been permanently wired into my brain on mouseUp put "that makes 2 of us" into response["Bernard"] end mouseUp Regards, Scott Rossi Creati

Re: Arrays and Custom Props

Don't feel too bad. So the dictionary does contain an example for what you needed, but after 6 years of using Revolution I still have to look up how do work with custompropertysets & arrays almost every time I use them together! Not to mention that I can never remember which way round 'split' & '

Re: Arrays and Custom Props

First example: "...myPropertiesArray". Boy, do I feel dumb. Thank you, Thierry. G. On Fri, Feb 13, 2009, at 1:00 PM, use-revolution-requ...@lists.runrev.com wrote: Le 13 févr. 09 à 17:55, Gregory Lypny a écrit : Hello Everyone, If I'm not mistaken, I recall read

Re: Arrays and Custom Props

Le 13 févr. 09 à 17:55, Gregory Lypny a écrit : Hello Everyone, If I'm not mistaken, I recall reading something a while back that an array can now be a custom prop and that there was an easy way to get a listing of all your custom props. I can't seem to find it. If anyone can

Re: Arrays: new and old keys, ii

-Original Message- >From: Brian Yennie <[EMAIL PROTECTED]> >So what would it be? A "combine" command which sorts the keys? Or >returns things in the order they were added? Or? > Last-In-First-Out (LIFO) or First-In-First-Out (FIFO) I would like to see that. I could us that. I could p

Re: Arrays: new and old keys, ii

To be fair, lots of languages use hash tables for arrays. And one could argue that associative arrays are not the data structure of choice for storing ordered data. I agree that some of this stuff would be useful, but if you really get down to it, "true arrays" often leave tasks like sortin

Re: Arrays: new and old keys, ii

One point of speculation which would make a huge difference is how Rev is actually implementing the arrays. If it is truly a hash table, providing any sort of in-order traversal of the array elements won't be happening any time soon. A hash table is an unordered piece of data, and so to provid

Re: Arrays: new and old keys, i

-Original Message- >From: Brian Yennie <[EMAIL PROTECTED]> \> >This is all very clever (seriously!), but I think this thread is >simply talking about two different things. It is one thing to maintain >your own sorting information in arrays. It's another to pull the data >out of arrays

Re: Arrays: new and old keys, i

This is all very clever (seriously!), but I think this thread is simply talking about two different things. It is one thing to maintain your own sorting information in arrays. It's another to pull the data out of arrays, then sort it. But it's another entirely to have sortable array. When y

Re: Arrays: new and old keys, i

-Original Message- >From: David Bovill <[EMAIL PROTECTED]> >Mark - looking at your script this is NOT doing what we need. It is not >sorting the keys - it is simply sorting a list, which happens to be inside >of an array. By that I mean nothing is actually happening to the array - you >simp

Re: Arrays: new and old keys, i

Mark you lost me on this thread somewhere: 2008/9/14 Mark Brownell <[EMAIL PROTECTED]> > We can have both worlds right now. If you need sorted and unsorted keys & > order of entry per dimensional layer or not all you need do is add layer [9] > assuming you will never need layer 9. Sorry what's

Re: Arrays: new and old keys, i

>From: Mark Wieder <[EMAIL PROTECTED]> ... >Maybe a property of arrays would do this: > >set the sortorder of theDataA to empty -- unsorted, fastest >set the sortorder of theDataA to "first input" -- FIFO >set the sortorder of theDataA to "last input" -- LFIFO >set the sortorder of theDataA to "alp

Re: Arrays: new and old keys, i

2008/9/14 Richard Gaskin <[EMAIL PROTECTED]> > > put tMyData[5] into tMySnippetA > put tMySnippetA["title"] > put tMySnippetA["body"] > > Are there cases where putting your arrays inside of ordinal wrapper arrays > would be problematic? Most of the time I don't want the complexity - the order

Re: Arrays: new and old keys, i

Ken- Saturday, September 13, 2008, 10:25:58 PM, you wrote: > "What benefit is it to the Rev developer (not the engine) to have the keys > NOT sorted?" I agree. While I don't think it's a traditional role of arrays to have their keys sorted and hash tables have their own internal key sorting, I t

Re: Arrays: new and old keys, i

Mark- Thanks for doing the timing on this. I believe it's not just multidimensional arrays that are faster now, but a part of the new engine changes is that arrays with solely numeric indices are treated differently from associative arrays. They're about as close to the metal as you can get and so

Re: Arrays: new and old keys, i

On Sep 14, 2008, at 1:25 AM, Ken Ray wrote: "What benefit is it to the Rev developer (not the engine) to have the keys NOT sorted?" I can't think of a really good everyday example, but here's a made up one: Suppose you're asking people for a list of possessions, and want them to pick of

Re: Arrays: new and old keys, i

David Bovill wrote: 2008/9/14 Richard Gaskin For accessing specific elements from large collections, arrays outperform any lineoffset in lists or any other method I can think of by several orders of magnitude.* Read, "It's a good hash mechanism". :) When I need ordinal sequential access, I u

Re: Arrays: new and old keys, i

Also, there seems to be a speed advantage with using the multi- dimesional arrays: on mouseUp put the millisecs into ts repeat with i = 1 to 1000 repeat with j = 1 to 1000 put "counting" into tArray[i,j] end repeat end repeat put the millisecs - ts into inTime

Re: Arrays: new and old keys, i

I believe that it's in the nature of hash tables (which is what Rev's arrays are, I think) that they do not preserve the order of keys. If so, then the engine would have to maintain an ordered index separately. This would likely affect performance, so perhaps we wouldn't always want it...

Re: Arrays: new and old keys, i

On 9/13/08 10:38 PM, "Dick Kriesel" <[EMAIL PROTECTED]> wrote: > Maybe the benefit of unsorted keys is faster execution. Why wait for a sort > if you don't need it? I believe the logic in the realm of PHP and web pages and databases are often-used functions such as explode(' ',explode(',', expo

Re: Arrays: new and old keys, i

Maybe the benefit of unsorted keys is faster execution. Why wait for a sort if you don't need it? On 9/13/08 10:25 PM, "Ken Ray" <[EMAIL PROTECTED]> wrote: > >> That would do me - except the most useful would be the ability to get the >> full ordered index. >> >> put the ordered keys of theDa

Re: Arrays: new and old keys, i

Ken Ray wrote: "What benefit is it to the Rev developer (not the engine) to have the keys NOT sorted?" I mean, I understand why the *engine* may want to keep the keys in a special order, but every time I work with the keys of an array, either (a) I don't care what order they're in, or (b) I rea

Re: Arrays: new and old keys, i

> That would do me - except the most useful would be the ability to get the > full ordered index. > > put the ordered keys of theDataA > > Because you want to things like: > > repeat for each key sortedKey in theDataA I've been watching this thread and I have to ask: "What benefit is it to th

Re: Arrays: new and old keys, i

2008/9/13 Mark Wieder <[EMAIL PROTECTED]> > > push "title 1" onto theDataA[] > push "title 2" onto theDataA[] > pop theDataA[] into tCurrentTitle That would do me - except the most useful would be the ability to get the full ordered index. put the ordered keys of theDataA Because you want to t

Re: Arrays: new and old keys, i

On Sep 13, 2008, at 2:38 PM, Mark Wieder wrote: Saturday, September 13, 2008, 6:10:42 AM, you wrote: Why force the developer to enforce an order after the fact? That is My point is rather that there's no need to impose an order on data that isn't ordered. Or at least not chronological order

Re: Arrays: new and old keys, i

Trevor- Saturday, September 13, 2008, 6:10:42 AM, you wrote: > Why force the developer to enforce an order after the fact? That is My point is rather that there's no need to impose an order on data that isn't ordered. Or at least not chronological order on xml data. > In addition once you have

Re: Arrays: new and old keys, i

David- Saturday, September 13, 2008, 3:41:51 AM, you wrote: > yes it is doable and not really "hard". So I think we are on the same wave > length. We differ in that I'm complaining about it :) > For beginners - it is counter intuitive (I remember having to ask on list > about it when learning

Re: Arrays: new and old keys, i

On Sep 13, 2008, at 12:22 PM, Mark Brownell wrote: What about using "after" if you want order instead of "into." "After" could cause order for those that need it. It would be great for me because I could do this: "put thisData after myArray[1][1]" "put myArray[1][1][4] into holdParameterIm

Re: Arrays: new and old keys, i

-Original Message- >From: Colin Holgate <[EMAIL PROTECTED]> >On Sep 13, 2008, at 1:08 PM, Mark Brownell wrote: > >> Wow, this is all coming back to me. The discussion list would fire >> up with two or three chiming in, in just a few seconds/minutes with >> work arounds for coding with

Re: Arrays: new and old keys, i

On Sep 13, 2008, at 1:08 PM, Mark Brownell wrote: Wow, this is all coming back to me. The discussion list would fire up with two or three chiming in, in just a few seconds/minutes with work arounds for coding with lists and parameter lists. There were always these, beat ya moments. I'm n

Re: Arrays: new and old keys, i

>> I'm going to do some experimenting now with Rev, or, have you >> already discovered these array within array tricks in single lines >> of code? > >Just doing v3 update now. Will report back soon! > Wow, this is all coming back to me. The discussion list would fire up with two or three ch

Re: Arrays: new and old keys, i

On Sep 13, 2008, at 12:53 PM, Mark Brownell wrote: I'm going to do some experimenting now with Rev, or, have you already discovered these array within array tricks in single lines of code? Just doing v3 update now. Will report back soon! ___ us

Re: Arrays: new and old keys, i

>peoplelist = [[name:"Tom",height:"72",city:"New York"], >[name:"Dick",height:"68",city:"San Francisco"], >[name:"Harry",height:"74",city:"New York"]] > >put peoplelist >-- [[#name: "Tom", #height: "72", #city: "New York"], [#height: >"68",#name: "Dick", #city: "San Francisco"], [#name: "Harry

Re: Arrays: new and old keys, i

On Sep 13, 2008, at 12:22 PM, Mark Brownell wrote: It's been a while but I believe that that ordering is how the Lists worked in Director. You didn't assign them key names. They could have parameters too, divided by ":" You just put data into an ordered spot. To be honest I like the non o

Re: Arrays: new and old keys, i

> >Multi-dimensional arrays are a powerful addition to Revolution as it >provides a basis for more powerful array manipulation features in the >engine moving forward. I feel that ordered keys form the basis for a >lot of those features. > >Trevor DeVore Good idea. It's been a while but I be

Re: Arrays: new and old keys, i

On 13 Sep 2008, at 09:37, John Vokey wrote: Again, I ask, what have we gained by the ``new'' array features, besides more brackets? Maybe you're more of a hands on guy, and no explanation found on this world will ever give you the same "aha" like trying it out yourself. Barring that, her

Re: Arrays: new and old keys, i

On Sep 13, 2008, at 12:37 AM, John Vokey wrote: Thank you all -- Please avoid sending me Word or PowerPoint attachments. See Joe Lewis Wilkins [EMAIL PROTECTED] ___

Re: Arrays: new and old keys, i

On Sep 13, 2008, at 12:36 AM, Mark Wieder wrote: Friday, September 12, 2008, 10:22:26 AM, you wrote: Belgian Waffles $5.95 two of our famous Belgian Waffles with plenty of real maple syrup 650 ... Sorry,

Re: Arrays: new and old keys, i

2008/9/13 Mark Wieder <[EMAIL PROTECTED]> > > Still not getting it here. I often do that with arrays, but I just use > a multipart key (and now I can use multidimensional array keys). I've > never needed to retrieve elements in the order added and still can't > see the utility of it. The following

Re: Arrays: new and old keys, i

>Subject: Re: Arrays: new and old keys, i > >Thank you all, for this discussion. Really. It was more informative >than the release notes could even hope to be. The exemplars of why >the new array features were so obviously useful helped me a lot in >exactly one way: I

Re: Arrays: new and old keys, i

Thank you all, for this discussion. Really. It was more informative than the release notes could even hope to be. The exemplars of why the new array features were so obviously useful helped me a lot in exactly one way: I have no idea what you who promote these ``new'' features are on abo

Re: Arrays: new and old keys

sorry, I'm on digest mode. >> put myArray["#476532"][4][3] into shippingPriceWestCoast > >I would assume you'd also be able to do: > > put myArray["#476532"]["shipping"]["west"] into shippingPriceWestCoast > >Right? > >Ken Ray Ken, Yes, right, you could. I'm mentioning it because you can use v

Re: Arrays: new and old keys, i

David- Friday, September 12, 2008, 2:23:23 PM, you wrote: > Mark I often need the chronological order. Examples of the top I my head > include routines to parse, scripts and create outlines for handlers, or wiki > text and construct outlines for titles, or tree structures where i want to > store

Re: Arrays: new and old keys, i

Trevor- Friday, September 12, 2008, 10:22:26 AM, you wrote: > To finish with, let's look at another XML example I grabbed from one > of the w3schools samples. > > > Belgian Waffles > $5.95 > two of our famous Belgian Waffles with plenty o

Re: Arrays: new and old keys, i

2008/9/12 Mark Wieder <[EMAIL PROTECTED]> > Trevor- > > Thursday, September 11, 2008, 2:20:36 PM, you wrote: > > > > I'm thinking of how PHP behaves. Arrays in PHP know the order that > > elements were added so that when you use foreach you get the elements > > in that same order. I always found t

Re: Arrays: new and old keys, i

> Can anybody explain what the new array format provides that the old > did not? All these bizarre examples seem not so much as exemplifying > the ``new'' features as to leave me baffled as to what added value > they provide. In NONE of the supposed or alleged examples have I seen > anything I c

Re: Arrays: new and old keys, i

On Sep 12, 2008, at 12:37 PM, Mark Wieder wrote: But I'm sorry to say that I can't think of a situation in which chronological order would be helpful. Obviously you've got a scenario where this works - could you enlighten me? I can try :-) Let's look at a few examples. I will start with a sim

Re: Arrays: new and old keys

> > Wheel Parts > "blah blah" > $249.99 > > > > $12.55 > > > put myArray["#476532"][4][3] into shippingPriceWestCoast I would assume you'd also be able to do: put myArray["#476532"]["shipping"]["west"] into shippingPriceWestCoast Right? Ken Ray Sons of Thunder Software, Inc

Re: Arrays: new and old keys, i

Trevor- Thursday, September 11, 2008, 2:20:36 PM, you wrote: > I'm thinking of how PHP behaves. Arrays in PHP know the order that > elements were added so that when you use foreach you get the elements > in that same order. I always found this very useful when working with > arrays in PHP. AF

  1   2   3   >