Re: Find vs. Offset

Thank you kindly. Mind you, it didn't start off clean. But that's the nice thing about LC, it's so easy to clean things up after the basic problem is solved. -- Peter Peter M. Brigham pmb...@gmail.com http://home.comcast.net/~pmbrig On Dec 28, 2012, at 1:18 PM, Geoff Canyon wrote: > I'm a big

Re: Find vs. Offset

I'm a big advocate of clean functions, and I just want to point out that this is really nicely done: clear, compact, efficient, documented, and the function name itself perfectly describes what it does. Really nice! On Wed, Dec 19, 2012 at 4:33 PM, Peter M. Brigham wrote: > function offsets str

Re: Subject: Re: Find vs. Offset

Yes, it's an sqlite database. Just call revOpenDatabase with the type parameter set to "sqlite" and ":memory:" in the path parameter. Pete lcSQL Software On Fri, Dec 21, 2012 at 2:39 PM, Mats Åström wrote: > How, exactly, does one create a database in RAM? > > The ":mem

Subject: Re: Find vs. Offset

How, exactly, does one create a database in RAM? The ":memory:" was a clue but from then... what kind of database - SQLite? /Mats, a RAM db ignorant ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscr

Re: Find vs. Offset

Pete, I'm intrigued. Please contact me off the list. Peter On Dec 19, 2012, at 5:59 PM, Peter Haworth wrote: > Good suggestion Mark. I'll jump in here. > > When you call revOpenDatabase, specify the path name as ":memory:". That > creates a database in memory instead of on disk which will di

Re: Find vs. Offset

Pete- Well, that was quick. I had to reboot my system, and when it came back up there was a ready-made answer. Peter- I got the hint about in-memory databases from Pete in the first place, so I'll just defer to him on this. Carry on. -- -Mark Wieder mwie...@ahsoftware.net __

Re: Find vs. Offset

Good suggestion Mark. I'll jump in here. When you call revOpenDatabase, specify the path name as ":memory:". That creates a database in memory instead of on disk which will disappear when you close your application. It does mean you'll have to create the tables/columns each time you open the da

Re: Find vs. Offset

Mark, that's new to me. Can you explain further? On Dec 19, 2012, at 5:15 PM, Mark Wieder wrote: > Peter- > > Wednesday, December 19, 2012, 4:03:43 PM, you wrote: > >> Thanks, Peter, that's what I was looking for. > >> Also, thanks Pete for the advice on using a database. That's what >> I used

Re: Find vs. Offset

Peter- Wednesday, December 19, 2012, 4:03:43 PM, you wrote: > Thanks, Peter, that's what I was looking for. > Also, thanks Pete for the advice on using a database. That's what > I used in a past, non-Livecode project, but unless the database can > be embedded in the main stack, I can't use that

Re: Find vs. Offset

On Dec 19, 2012, at 7:03 PM, Peter Brigham wrote: > > repeat for each item f in fieldlist > put offsets(tString,f) into tOffsets > if tOffsets = 0 then next repeat > repeat for each item i in tOffsets > A correction, I think you have to use "put offsets(tString, the text of f) into tOffsets

Re: Find vs. Offset

ement, >>> whereas "find" is pretty self reliant. >>> >>> >>> How would you use "offset" over multiple stacks anyway? Navigate to each >>> card in each stack, and then test each field in turn, noting if the offset >>> funct

Re: Find vs. Offset

" function can be tailored to find multiple instances. >> >> >> Perhaps a mixture of the two, "find" to get quickly to a card that has a >> hit, and then "offset" to find multiple instances? >> >> >> Craig Newman >> >>

Re: Find vs. Offset

Hi Peter, You might consider taking a look at the SQLite Full Text Search table functionality. It's easy to set up, harder to learn hot to retrieve stuff correctly. But it is lightning fast. Pete lcSQL Software On Tue, Dec 18, 2012 at 1:13 PM, Peter Bogdanoff wrote: >

Re: Find vs. Offset

Colin, Thanks. It is a reference work. However I'm allowing a string search which could be several words or parts of words. But I suppose an index could handle that. Peter On Dec 18, 2012, at 7:03 AM, Colin Holgate wrote: > If it's a reference book you could pre index all of the words, then h

Re: Find vs. Offset

On 12/18/12 11:55 AM, Robert Sneidar wrote: I did not know that! At least, I think I might have known that, and forgot, and then been reminded again, and then forgot again! Please see the code-lines/grey hair/baldness thread elsewhere. :) -- Jacqueline Landman Gay | jac...@hyperact

Re: Find vs. Offset

On 12/18/12 2:29 AM, Kay C Lan wrote: On Tue, Dec 18, 2012 at 12:28 PM, J. Landman Gay wrote: On 12/17/12 9:53 PM, Kay C Lan wrote: except it only lists one line even if there are multiple entries, and it doesn't have 3 words before and after. The 1-line entry is an ancient bug. Resize t

Re: Find vs. Offset

I did not know that! At least, I think I might have known that, and forgot, and then been reminded again, and then forgot again! Bob On Dec 17, 2012, at 7:04 PM, J. Landman Gay wrote: > On 12/17/12 5:54 PM, Peter Bogdanoff wrote: >> I do see that there is much more management with the "offset

Re: Find vs. Offset

If it's a reference book you could pre index all of the words, then have a find field that knows the list of words used in each page. You could quickly know which cards contain any given word (using offset), and could then go to those cards to do a local find, to highlight the word.

Re: Find vs. Offset

On Tue, Dec 18, 2012 at 12:28 PM, J. Landman Gay wrote: > On 12/17/12 9:53 PM, Kay C Lan wrote: > > except it only lists one line even if there are multiple >> entries, and it doesn't have 3 words before and after. >> > > The 1-line entry is an ancient bug. Resize the stack slightly and they all

Re: Find vs. Offset

So going to a stack and using the Find command is OK, speedwise? I'm searching 5 substacks, each with 200-500 cards. The Dictionary says that offset is faster. I was hoping that someone with eons of experience would say, "Nah, you should do such and such..." I guess I'll have to try both. Tha

Re: Find vs. Offset

On 12/17/12 9:53 PM, Kay C Lan wrote: Sorry, not an answer but a pointer. How does the IDE's Find and Replace do it? This searches multiple stacks without visibly visiting the stacks - you end where you started, at the Find and Replace stack. It basically does what you want, except it only lists

Re: Find vs. Offset

On Tue, Dec 18, 2012 at 7:54 AM, Peter Bogdanoff wrote: > I do see that there is much more management with the "offset", however, I > believe I can use the offset without having to actually navigate to the > other stack, and I found that going to another stack and using the "Find" > there unlocks

Re: Find vs. Offset

On 12/17/12 5:54 PM, Peter Bogdanoff wrote: I do see that there is much more management with the "offset", however, I believe I can use the offset without having to actually navigate to the other stack, and I found that going to another stack and using the "Find" there unlocks the screen (bad).

Re: Find vs. Offset

> > > > -Original Message- > From: Peter Bogdanoff > To: How to use LiveCode > Sent: Mon, Dec 17, 2012 6:31 pm > Subject: Find vs. Offset > > > Hi, > > I have a stack with multiple substacks. One of the substacks is a Search tool > to >

Re: Find vs. Offset

quickly to a card that has a hit, and then "offset" to find multiple instances? Craig Newman -Original Message- From: Peter Bogdanoff To: How to use LiveCode Sent: Mon, Dec 17, 2012 6:31 pm Subject: Find vs. Offset Hi, I have a stack with multiple substacks. One of the sub

Find vs. Offset

Hi, I have a stack with multiple substacks. One of the substacks is a Search tool to find text in the other substacks. Given a string to find, it searches the other stacks, returns a list of the cards where the string was found (there may be multiple hits on the same card), and puts excerpts of