Re: FindIndex question
other way, alex. use the pg, not the dg, for now. BUT, here's a good reason to use the dg - you can fix issues with it. the source of the pg is closed, and you can't get at it, AFAIK. check the issue tracker for issues with it. you can't address them. please, no comments from the peanut gallery on the status of lcb. that's a separate problem. SO, if the script compiler was in the wild, i would expect the dg to be faster. would it be as fast as the pg? dunno. but, again, you could work on it. On Mon, Mar 25, 2024 at 6:07 PM Alex Tweedly via use-livecode < use-livecode@lists.runrev.com> wrote: > Bob - I think you've mentioned these functions (and posted code, or a > pointer to code, for them) before (but I couldn't find it). Any chance > you could re-post (or just send to me, or ...) > > Mike - I couldn't see in the thread *why* you want to use a dg ather > than a pg ? Is there a missing capability you need ? Or some non-obvious > (to me) reason to avoid pg? > > Thanks, > > Alex. > > On 25/03/2024 18:50, Mike Kerner via use-livecode wrote: > > i guess what i'm wondering is how quickly or slowly the dg will render, > if > > the dgArray is large. it seems to be slower, when the array is larger. > > > > On Mon, Mar 25, 2024 at 2:48 PM Mike Kerner > > wrote: > > > >> i never heard of it called an "elevator". I anyways heard "thumb" > >> > >> On Mon, Mar 25, 2024 at 2:08 PM Bob Sneidar via use-livecode < > >> use-livecode@lists.runrev.com> wrote: > >> > >>> I’ve thought about that. A temporary memory database would not appear > to > >>> the user to be faster, as the initial query for a large dataset will > happen > >>> all at once during which Livecode would be unresponsive. And if you > page > >>> the queries from the live database, re-storing the data in a memory > >>> database would just be added time. > >>> > >>> You could use send in time to cache forward and backwards a few pages, > >>> and in that case a memory database could help, but if the user drags > the > >>> elevator box (how many people know what THAT is) then you go back to > square > >>> 1 concerning efficiency. > >>> > >>> Bob S > >>> > >>> > On Mar 25, 2024, at 10:34 AM, Mike Kerner via use-livecode < > >>> use-livecode@lists.runrev.com> wrote: > i would be curious to know if an in-memory sqlite db increases scroll > >>> speed > with dg's. > basically, you would live load the dg with pages from the db. > i can't imagine that the dg is faster than the pg. everything i've > tried > with the pg is faster than the dg. > just one more reason to resurrect the script compiler and release it. > > On Mon, Mar 25, 2024 at 11:16 AM Bob Sneidar via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > I wrote a findInArray() function that will convert an array to a > memory > > based SQL database, and one of the arguments is the SQL query > >>> statement to > > use on the database. I have another called FilterArray() which simply > > iterates through the keys to output those matching a criteria. > > > > Bob S > > > >> On Mar 24, 2024, at 2:22 PM, Neville Smythe via use-livecode < > > use-livecode@lists.runrev.com> wrote: > >> > >>> On 25 Mar 2024, at 3:00 am,Mike Kerner wrote: > >>> > >>> i don't know if you dove into the code, but it's too early to think > > about > >>> unpacking this, so here's the code: ... > >> Thanks Mike > >> > >> While I was aware of the optional parameters feature of LC commands > I > > have never used it I so was unfamiliar with the syntax. The penny had > >>> never > > dropped that the parameter list for a command is just an array, so > > evidently you can actually send an array instead of a comma delimited > >>> list > >> Which means that you can send FindIndex a single parameter > pKeyPairsA > > which is an array with alternating colName,searchStr values > >> Setting up such an array is not particularly convenient for coding > > however. My workaround had been to use a custom function hack > >> function myFindIndex pDataGrid, pKeyPairs > >> — pKeyPairs is a comma delimited list such as > > “colname1,str1,colname2,str2,..” > >>replace comma with quote & comma & quote in pKeyPairs > >>put “dispatch FindIndex to” && pDataGrid && “with” && quote & > > pKeyPairs & quote into tCommandStr > >>do tCommandstr > >> put the result into tFoundIndex > >> ... > >> > >> A much more elegant (if probably no faster) solution is > >> > >> function myFindIndex pDataGrid, pKeyPairs > >> — pKeyPairs is a comma delimited list such as > > “colname1,str1,colname2,str2,..” > >>set the columnDelimiter to comma > >>split pKeyPairs by column > >>dispatch “FindIndex" to pDataGrid with pKeyPairs > >> put the result into tFoundIndex > >> ... > >> > >> > >> BTW, where
Re: FindIndex question
This is the code with a couple of dependencies. I think that’s all the
fiddlybits. If I missed something let me know.
Bob S
function filterArray pArrayDataA, pConditions
put the defaultFolder & "/" & "tempdatabase.db" into tDBName
put arrayToSQLite(pArrayDataA, tDBName, "arraydata") into tDBID
put "select * from arraydata where" && pConditions into tQueryString
try
put revQueryDatabase(tDBID, tQueryString) into tCursorID
put cursorToArray(tCursorID) into tFilteredDataA
return tFilteredDataA
catch tError
return empty
end try
end filterArray
FUNCTION arrayToSQLite pArrayDataA, pDBFile, pDBName, pDBID, pBinaryColumns
— The only argument required is pArrayData. Defaults will be used for the
rest
put the keys of pArrayDataA into tArrayKeys
sort tArrayKeys numeric ascending
IF pDBFile is empty THEN put ":memory:" into pDBFile
IF pDBName is empty THEN put "arraydata" into pDBName
TRY
if pDBID is empty then \
put revOpenDatabase("sqlite", pDBFile) into pDBID
IF "Error" is in pDBID THEN
return empty
END IF
-- attempt to set the encoding
put "PRAGMA encoding = 'UTF-16'" into tSQL
revExecuteSQL pDBID, tSQL
-- attempt to drop the table
put "drop table " & pDBName into tDropSQL
revExecuteSQL pDBID, tDropSQL
put the result into tResult
CATCH tError
answer tError
IF the environment is "development" THEN exit to top ELSE quit
END TRY
-- create the table
put "create table" && quote & pDBName & quote \
& cr into tCreateCommand
put "(" & quote & "recordid" & quote && "NUMERIC PRIMARY KEY UNIQUE, " \
& cr AFTER tCreateCommand
put the keys of pArrayDataA [1] into tRecordKeyList
filter lines of tRecordKeyList without "recordid"
REPEAT for each line tRecordKey in tRecordKeyList
if pArrayDataA [1] [tRecordKey] is an array or \
pArrayDataA [1] [tRecordKey] begins with "Salted__" then
put "BLOB" into tColumnType
else
put VARCHAR into tColumnType
end if
put quote & tRecordKey & quote && tColumnType & "," && cr AFTER
tCreateCommand
END REPEAT
delete char -3 to -1 of tCreateCommand
put ")" AFTER tCreateCommand
TRY
revExecuteSQL pDBID, tCreateCommand
put the result into tResult
IF tResult is not 0 THEN breakpoint
CATCH tError
breakpoint
END TRY
put 1 into tRecordCounter
put "recordid" & cr & tRecordKeyList into tColumns
repeat with i = 1 to the number of lines of tColumns
put ":" & i into item i of tColumnList
end repeat
put "(" & tColumnList & ")" into tColumnList
-- insert data
REPEAT for each line tKey in tArrayKeys
put 1 into tColumnCounter
put pArrayDataA [tKey] into tRecordDataA
put tRecordCounter into tQueryDataA [1]
REPEAT for each line tRecordKey in tRecordKeyList
add 1 to tColumnCounter
if tRecordDataA [tRecordKey] is an array then
put arrayEncode(tRecordDataA [tRecordKey]) into tValue
else
put tRecordDataA [tRecordKey] into tValue
end if
put tValue into tQueryDataA [tColumnCounter]
END REPEAT
put "insert into" && pDBName && "VALUES" && tColumnList into tInsertSQL
TRY
revExecuteSQL pDBID, tInsertSQL, "tQueryDataA"
put the result into tResult
if the result is not a number then breakpoint
CATCH tError
breakpoint
END TRY
add 1 to tRecordCounter
END REPEAT
return pDBID
END arrayToSQLite
FUNCTION cursorToArray pCursorID
put revNumberOfRecords(pCursorID) into tNumberOfRecords
if tNumberOfRecords = 0 then \
return empty
put revDatabaseColumnCount(pCursorID) into tColumnCount
put revDatabaseColumnNames(pCursorID) into tColumnNames
REPEAT forever
add 1 to tRecordCount
REPEAT with i = 1 to tColumnCount
put revDatabaseColumnNumbered(pCursorID, i) into tColumnValue
put tColumnValue into aCursorArray [tRecordCount] [item i of
tColumnNames]
END REPEAT
revMoveToNextRecord pCursorID
if revQueryIsAtEnd(pCursorID) then \
exit repeat
END REPEAT
return aCursorArray
END cursorToArray
> On Mar 25, 2024, at 3:06 PM, Alex Tweedly via use-livecode
> wrote:
>
> Bob - I think you've mentioned these functions (and posted code, or a pointer
> to code, for them) before (but I couldn't find it). Any chance you could
> re-post (or just send to me, or ...)
>
> Mike - I couldn't see in the thread *why* you want to use a dg ather than a
> pg ? Is there a missing capability you need ? Or some non-obvious (to me)
> reason to avoid pg?
>
> Thanks,
>
> Alex.
>
___
use-livecode mailing
Re: FindIndex question
Bob - I think you've mentioned these functions (and posted code, or a pointer to code, for them) before (but I couldn't find it). Any chance you could re-post (or just send to me, or ...) Mike - I couldn't see in the thread *why* you want to use a dg ather than a pg ? Is there a missing capability you need ? Or some non-obvious (to me) reason to avoid pg? Thanks, Alex. On 25/03/2024 18:50, Mike Kerner via use-livecode wrote: i guess what i'm wondering is how quickly or slowly the dg will render, if the dgArray is large. it seems to be slower, when the array is larger. On Mon, Mar 25, 2024 at 2:48 PM Mike Kerner wrote: i never heard of it called an "elevator". I anyways heard "thumb" On Mon, Mar 25, 2024 at 2:08 PM Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: I’ve thought about that. A temporary memory database would not appear to the user to be faster, as the initial query for a large dataset will happen all at once during which Livecode would be unresponsive. And if you page the queries from the live database, re-storing the data in a memory database would just be added time. You could use send in time to cache forward and backwards a few pages, and in that case a memory database could help, but if the user drags the elevator box (how many people know what THAT is) then you go back to square 1 concerning efficiency. Bob S On Mar 25, 2024, at 10:34 AM, Mike Kerner via use-livecode < use-livecode@lists.runrev.com> wrote: i would be curious to know if an in-memory sqlite db increases scroll speed with dg's. basically, you would live load the dg with pages from the db. i can't imagine that the dg is faster than the pg. everything i've tried with the pg is faster than the dg. just one more reason to resurrect the script compiler and release it. On Mon, Mar 25, 2024 at 11:16 AM Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: I wrote a findInArray() function that will convert an array to a memory based SQL database, and one of the arguments is the SQL query statement to use on the database. I have another called FilterArray() which simply iterates through the keys to output those matching a criteria. Bob S On Mar 24, 2024, at 2:22 PM, Neville Smythe via use-livecode < use-livecode@lists.runrev.com> wrote: On 25 Mar 2024, at 3:00 am,Mike Kerner wrote: i don't know if you dove into the code, but it's too early to think about unpacking this, so here's the code: ... Thanks Mike While I was aware of the optional parameters feature of LC commands I have never used it I so was unfamiliar with the syntax. The penny had never dropped that the parameter list for a command is just an array, so evidently you can actually send an array instead of a comma delimited list Which means that you can send FindIndex a single parameter pKeyPairsA which is an array with alternating colName,searchStr values Setting up such an array is not particularly convenient for coding however. My workaround had been to use a custom function hack function myFindIndex pDataGrid, pKeyPairs — pKeyPairs is a comma delimited list such as “colname1,str1,colname2,str2,..” replace comma with quote & comma & quote in pKeyPairs put “dispatch FindIndex to” && pDataGrid && “with” && quote & pKeyPairs & quote into tCommandStr do tCommandstr put the result into tFoundIndex ... A much more elegant (if probably no faster) solution is function myFindIndex pDataGrid, pKeyPairs — pKeyPairs is a comma delimited list such as “colname1,str1,colname2,str2,..” set the columnDelimiter to comma split pKeyPairs by column dispatch “FindIndex" to pDataGrid with pKeyPairs put the result into tFoundIndex ... BTW, where did you find the source code for DataGrid handlers? I now see how one could write a FindIndices function to return all indices rather than just the first found … or even a general WHERE search :-) Neville Smythe ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___
Re: FindIndex question
i guess what i'm wondering is how quickly or slowly the dg will render, if the dgArray is large. it seems to be slower, when the array is larger. On Mon, Mar 25, 2024 at 2:48 PM Mike Kerner wrote: > i never heard of it called an "elevator". I anyways heard "thumb" > > On Mon, Mar 25, 2024 at 2:08 PM Bob Sneidar via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> I’ve thought about that. A temporary memory database would not appear to >> the user to be faster, as the initial query for a large dataset will happen >> all at once during which Livecode would be unresponsive. And if you page >> the queries from the live database, re-storing the data in a memory >> database would just be added time. >> >> You could use send in time to cache forward and backwards a few pages, >> and in that case a memory database could help, but if the user drags the >> elevator box (how many people know what THAT is) then you go back to square >> 1 concerning efficiency. >> >> Bob S >> >> >> > On Mar 25, 2024, at 10:34 AM, Mike Kerner via use-livecode < >> use-livecode@lists.runrev.com> wrote: >> > >> > i would be curious to know if an in-memory sqlite db increases scroll >> speed >> > with dg's. >> > basically, you would live load the dg with pages from the db. >> > i can't imagine that the dg is faster than the pg. everything i've tried >> > with the pg is faster than the dg. >> > just one more reason to resurrect the script compiler and release it. >> > >> > On Mon, Mar 25, 2024 at 11:16 AM Bob Sneidar via use-livecode < >> > use-livecode@lists.runrev.com> wrote: >> > >> >> I wrote a findInArray() function that will convert an array to a memory >> >> based SQL database, and one of the arguments is the SQL query >> statement to >> >> use on the database. I have another called FilterArray() which simply >> >> iterates through the keys to output those matching a criteria. >> >> >> >> Bob S >> >> >> >>> On Mar 24, 2024, at 2:22 PM, Neville Smythe via use-livecode < >> >> use-livecode@lists.runrev.com> wrote: >> >>> >> >>> >> On 25 Mar 2024, at 3:00 am,Mike Kerner wrote: >> >> i don't know if you dove into the code, but it's too early to think >> >> about >> unpacking this, so here's the code: ... >> >>> >> >>> Thanks Mike >> >>> >> >>> While I was aware of the optional parameters feature of LC commands I >> >> have never used it I so was unfamiliar with the syntax. The penny had >> never >> >> dropped that the parameter list for a command is just an array, so >> >> evidently you can actually send an array instead of a comma delimited >> list >> >>> >> >>> Which means that you can send FindIndex a single parameter pKeyPairsA >> >> which is an array with alternating colName,searchStr values >> >>> >> >>> Setting up such an array is not particularly convenient for coding >> >> however. My workaround had been to use a custom function hack >> >>> >> >>> function myFindIndex pDataGrid, pKeyPairs >> >>> — pKeyPairs is a comma delimited list such as >> >> “colname1,str1,colname2,str2,..” >> >>> >> >>> replace comma with quote & comma & quote in pKeyPairs >> >>> put “dispatch FindIndex to” && pDataGrid && “with” && quote & >> >> pKeyPairs & quote into tCommandStr >> >>> do tCommandstr >> >>> put the result into tFoundIndex >> >>> ... >> >>> >> >>> A much more elegant (if probably no faster) solution is >> >>> >> >>> function myFindIndex pDataGrid, pKeyPairs >> >>> — pKeyPairs is a comma delimited list such as >> >> “colname1,str1,colname2,str2,..” >> >>> >> >>> set the columnDelimiter to comma >> >>> split pKeyPairs by column >> >>> dispatch “FindIndex" to pDataGrid with pKeyPairs >> >>> put the result into tFoundIndex >> >>> ... >> >>> >> >>> >> >>> BTW, where did you find the source code for DataGrid handlers? I now >> see >> >> how one could write a FindIndices function to return all indices rather >> >> than just the first found … or even a general WHERE search :-) >> >>> >> >>> Neville Smythe >> >>> >> >>> >> >>> >> >>> >> >>> ___ >> >>> use-livecode mailing list >> >>> use-livecode@lists.runrev.com >> >>> Please visit this url to subscribe, unsubscribe and manage your >> >> subscription preferences: >> >>> http://lists.runrev.com/mailman/listinfo/use-livecode >> >> >> >> ___ >> >> use-livecode mailing list >> >> use-livecode@lists.runrev.com >> >> Please visit this url to subscribe, unsubscribe and manage your >> >> subscription preferences: >> >> http://lists.runrev.com/mailman/listinfo/use-livecode >> >> >> > >> > >> > -- >> > On the first day, God created the heavens and the Earth >> > On the second day, God created the oceans. >> > On the third day, God put the animals on hold for a few hours, >> > and did a little diving. >> > And God said, "This is good." >> > ___ >> > use-livecode mailing list >> > use-livecode@lists.runrev.com >> > Please
Re: FindIndex question
i never heard of it called an "elevator". I anyways heard "thumb" On Mon, Mar 25, 2024 at 2:08 PM Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > I’ve thought about that. A temporary memory database would not appear to > the user to be faster, as the initial query for a large dataset will happen > all at once during which Livecode would be unresponsive. And if you page > the queries from the live database, re-storing the data in a memory > database would just be added time. > > You could use send in time to cache forward and backwards a few pages, and > in that case a memory database could help, but if the user drags the > elevator box (how many people know what THAT is) then you go back to square > 1 concerning efficiency. > > Bob S > > > > On Mar 25, 2024, at 10:34 AM, Mike Kerner via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > i would be curious to know if an in-memory sqlite db increases scroll > speed > > with dg's. > > basically, you would live load the dg with pages from the db. > > i can't imagine that the dg is faster than the pg. everything i've tried > > with the pg is faster than the dg. > > just one more reason to resurrect the script compiler and release it. > > > > On Mon, Mar 25, 2024 at 11:16 AM Bob Sneidar via use-livecode < > > use-livecode@lists.runrev.com> wrote: > > > >> I wrote a findInArray() function that will convert an array to a memory > >> based SQL database, and one of the arguments is the SQL query statement > to > >> use on the database. I have another called FilterArray() which simply > >> iterates through the keys to output those matching a criteria. > >> > >> Bob S > >> > >>> On Mar 24, 2024, at 2:22 PM, Neville Smythe via use-livecode < > >> use-livecode@lists.runrev.com> wrote: > >>> > >>> > On 25 Mar 2024, at 3:00 am,Mike Kerner wrote: > > i don't know if you dove into the code, but it's too early to think > >> about > unpacking this, so here's the code: ... > >>> > >>> Thanks Mike > >>> > >>> While I was aware of the optional parameters feature of LC commands I > >> have never used it I so was unfamiliar with the syntax. The penny had > never > >> dropped that the parameter list for a command is just an array, so > >> evidently you can actually send an array instead of a comma delimited > list > >>> > >>> Which means that you can send FindIndex a single parameter pKeyPairsA > >> which is an array with alternating colName,searchStr values > >>> > >>> Setting up such an array is not particularly convenient for coding > >> however. My workaround had been to use a custom function hack > >>> > >>> function myFindIndex pDataGrid, pKeyPairs > >>> — pKeyPairs is a comma delimited list such as > >> “colname1,str1,colname2,str2,..” > >>> > >>> replace comma with quote & comma & quote in pKeyPairs > >>> put “dispatch FindIndex to” && pDataGrid && “with” && quote & > >> pKeyPairs & quote into tCommandStr > >>> do tCommandstr > >>> put the result into tFoundIndex > >>> ... > >>> > >>> A much more elegant (if probably no faster) solution is > >>> > >>> function myFindIndex pDataGrid, pKeyPairs > >>> — pKeyPairs is a comma delimited list such as > >> “colname1,str1,colname2,str2,..” > >>> > >>> set the columnDelimiter to comma > >>> split pKeyPairs by column > >>> dispatch “FindIndex" to pDataGrid with pKeyPairs > >>> put the result into tFoundIndex > >>> ... > >>> > >>> > >>> BTW, where did you find the source code for DataGrid handlers? I now > see > >> how one could write a FindIndices function to return all indices rather > >> than just the first found … or even a general WHERE search :-) > >>> > >>> Neville Smythe > >>> > >>> > >>> > >>> > >>> ___ > >>> use-livecode mailing list > >>> use-livecode@lists.runrev.com > >>> Please visit this url to subscribe, unsubscribe and manage your > >> subscription preferences: > >>> http://lists.runrev.com/mailman/listinfo/use-livecode > >> > >> ___ > >> use-livecode mailing list > >> use-livecode@lists.runrev.com > >> Please visit this url to subscribe, unsubscribe and manage your > >> subscription preferences: > >> http://lists.runrev.com/mailman/listinfo/use-livecode > >> > > > > > > -- > > On the first day, God created the heavens and the Earth > > On the second day, God created the oceans. > > On the third day, God put the animals on hold for a few hours, > > and did a little diving. > > And God said, "This is good." > > ___ > > use-livecode mailing list > > use-livecode@lists.runrev.com > > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > > http://lists.runrev.com/mailman/listinfo/use-livecode > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your >
Re: FindIndex question
I’ve thought about that. A temporary memory database would not appear to the user to be faster, as the initial query for a large dataset will happen all at once during which Livecode would be unresponsive. And if you page the queries from the live database, re-storing the data in a memory database would just be added time. You could use send in time to cache forward and backwards a few pages, and in that case a memory database could help, but if the user drags the elevator box (how many people know what THAT is) then you go back to square 1 concerning efficiency. Bob S > On Mar 25, 2024, at 10:34 AM, Mike Kerner via use-livecode > wrote: > > i would be curious to know if an in-memory sqlite db increases scroll speed > with dg's. > basically, you would live load the dg with pages from the db. > i can't imagine that the dg is faster than the pg. everything i've tried > with the pg is faster than the dg. > just one more reason to resurrect the script compiler and release it. > > On Mon, Mar 25, 2024 at 11:16 AM Bob Sneidar via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> I wrote a findInArray() function that will convert an array to a memory >> based SQL database, and one of the arguments is the SQL query statement to >> use on the database. I have another called FilterArray() which simply >> iterates through the keys to output those matching a criteria. >> >> Bob S >> >>> On Mar 24, 2024, at 2:22 PM, Neville Smythe via use-livecode < >> use-livecode@lists.runrev.com> wrote: >>> >>> On 25 Mar 2024, at 3:00 am,Mike Kerner wrote: i don't know if you dove into the code, but it's too early to think >> about unpacking this, so here's the code: ... >>> >>> Thanks Mike >>> >>> While I was aware of the optional parameters feature of LC commands I >> have never used it I so was unfamiliar with the syntax. The penny had never >> dropped that the parameter list for a command is just an array, so >> evidently you can actually send an array instead of a comma delimited list >>> >>> Which means that you can send FindIndex a single parameter pKeyPairsA >> which is an array with alternating colName,searchStr values >>> >>> Setting up such an array is not particularly convenient for coding >> however. My workaround had been to use a custom function hack >>> >>> function myFindIndex pDataGrid, pKeyPairs >>> — pKeyPairs is a comma delimited list such as >> “colname1,str1,colname2,str2,..” >>> >>> replace comma with quote & comma & quote in pKeyPairs >>> put “dispatch FindIndex to” && pDataGrid && “with” && quote & >> pKeyPairs & quote into tCommandStr >>> do tCommandstr >>> put the result into tFoundIndex >>> ... >>> >>> A much more elegant (if probably no faster) solution is >>> >>> function myFindIndex pDataGrid, pKeyPairs >>> — pKeyPairs is a comma delimited list such as >> “colname1,str1,colname2,str2,..” >>> >>> set the columnDelimiter to comma >>> split pKeyPairs by column >>> dispatch “FindIndex" to pDataGrid with pKeyPairs >>> put the result into tFoundIndex >>> ... >>> >>> >>> BTW, where did you find the source code for DataGrid handlers? I now see >> how one could write a FindIndices function to return all indices rather >> than just the first found … or even a general WHERE search :-) >>> >>> Neville Smythe >>> >>> >>> >>> >>> ___ >>> use-livecode mailing list >>> use-livecode@lists.runrev.com >>> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >>> http://lists.runrev.com/mailman/listinfo/use-livecode >> >> ___ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > > > -- > On the first day, God created the heavens and the Earth > On the second day, God created the oceans. > On the third day, God put the animals on hold for a few hours, > and did a little diving. > And God said, "This is good." > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: FindIndex question
i would be curious to know if an in-memory sqlite db increases scroll speed with dg's. basically, you would live load the dg with pages from the db. i can't imagine that the dg is faster than the pg. everything i've tried with the pg is faster than the dg. just one more reason to resurrect the script compiler and release it. On Mon, Mar 25, 2024 at 11:16 AM Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > I wrote a findInArray() function that will convert an array to a memory > based SQL database, and one of the arguments is the SQL query statement to > use on the database. I have another called FilterArray() which simply > iterates through the keys to output those matching a criteria. > > Bob S > > > On Mar 24, 2024, at 2:22 PM, Neville Smythe via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > > >> On 25 Mar 2024, at 3:00 am,Mike Kerner wrote: > >> > >> i don't know if you dove into the code, but it's too early to think > about > >> unpacking this, so here's the code: ... > > > > Thanks Mike > > > > While I was aware of the optional parameters feature of LC commands I > have never used it I so was unfamiliar with the syntax. The penny had never > dropped that the parameter list for a command is just an array, so > evidently you can actually send an array instead of a comma delimited list > > > > Which means that you can send FindIndex a single parameter pKeyPairsA > which is an array with alternating colName,searchStr values > > > > Setting up such an array is not particularly convenient for coding > however. My workaround had been to use a custom function hack > > > > function myFindIndex pDataGrid, pKeyPairs > > — pKeyPairs is a comma delimited list such as > “colname1,str1,colname2,str2,..” > > > >replace comma with quote & comma & quote in pKeyPairs > >put “dispatch FindIndex to” && pDataGrid && “with” && quote & > pKeyPairs & quote into tCommandStr > >do tCommandstr > > put the result into tFoundIndex > > ... > > > > A much more elegant (if probably no faster) solution is > > > > function myFindIndex pDataGrid, pKeyPairs > > — pKeyPairs is a comma delimited list such as > “colname1,str1,colname2,str2,..” > > > >set the columnDelimiter to comma > >split pKeyPairs by column > >dispatch “FindIndex" to pDataGrid with pKeyPairs > > put the result into tFoundIndex > > ... > > > > > > BTW, where did you find the source code for DataGrid handlers? I now see > how one could write a FindIndices function to return all indices rather > than just the first found … or even a general WHERE search :-) > > > > Neville Smythe > > > > > > > > > > ___ > > use-livecode mailing list > > use-livecode@lists.runrev.com > > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > > http://lists.runrev.com/mailman/listinfo/use-livecode > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: FindIndex question
I wrote a findInArray() function that will convert an array to a memory based SQL database, and one of the arguments is the SQL query statement to use on the database. I have another called FilterArray() which simply iterates through the keys to output those matching a criteria. Bob S > On Mar 24, 2024, at 2:22 PM, Neville Smythe via use-livecode > wrote: > > >> On 25 Mar 2024, at 3:00 am,Mike Kerner wrote: >> >> i don't know if you dove into the code, but it's too early to think about >> unpacking this, so here's the code: ... > > Thanks Mike > > While I was aware of the optional parameters feature of LC commands I have > never used it I so was unfamiliar with the syntax. The penny had never > dropped that the parameter list for a command is just an array, so evidently > you can actually send an array instead of a comma delimited list > > Which means that you can send FindIndex a single parameter pKeyPairsA which > is an array with alternating colName,searchStr values > > Setting up such an array is not particularly convenient for coding however. > My workaround had been to use a custom function hack > > function myFindIndex pDataGrid, pKeyPairs > — pKeyPairs is a comma delimited list such as > “colname1,str1,colname2,str2,..” > >replace comma with quote & comma & quote in pKeyPairs >put “dispatch FindIndex to” && pDataGrid && “with” && quote & pKeyPairs & > quote into tCommandStr >do tCommandstr > put the result into tFoundIndex > ... > > A much more elegant (if probably no faster) solution is > > function myFindIndex pDataGrid, pKeyPairs > — pKeyPairs is a comma delimited list such as > “colname1,str1,colname2,str2,..” > >set the columnDelimiter to comma >split pKeyPairs by column >dispatch “FindIndex" to pDataGrid with pKeyPairs > put the result into tFoundIndex > ... > > > BTW, where did you find the source code for DataGrid handlers? I now see how > one could write a FindIndices function to return all indices rather than just > the first found … or even a general WHERE search :-) > > Neville Smythe > > > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: FindIndex question
just to sanitycheck myself, i opened 9.6.9, created a new stack, and added a dg to it. then i fired up the pb. expand the card, and you'll see the dg. there are two behaviors assigned to the dg. the first is button id 1005 of stack "revDataGridLibrary" which has, as its behavior, stack "RevDataGridLibraryBehaviorsDataGridButtonBehavior" On Sun, Mar 24, 2024 at 9:59 PM Mike Kerner wrote: > it's in the behavior of the dg > you can also go digging through the OSS repo, if you like. > > > On Sun, Mar 24, 2024 at 5:23 PM Neville Smythe via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> >> > On 25 Mar 2024, at 3:00 am,Mike Kerner wrote: >> > >> > i don't know if you dove into the code, but it's too early to think >> about >> > unpacking this, so here's the code: ... >> >> Thanks Mike >> >> While I was aware of the optional parameters feature of LC commands I >> have never used it I so was unfamiliar with the syntax. The penny had never >> dropped that the parameter list for a command is just an array, so >> evidently you can actually send an array instead of a comma delimited list >> >> Which means that you can send FindIndex a single parameter pKeyPairsA >> which is an array with alternating colName,searchStr values >> >> Setting up such an array is not particularly convenient for coding >> however. My workaround had been to use a custom function hack >> >> function myFindIndex pDataGrid, pKeyPairs >>— pKeyPairs is a comma delimited list such as >> “colname1,str1,colname2,str2,..” >> >> replace comma with quote & comma & quote in pKeyPairs >> put “dispatch FindIndex to” && pDataGrid && “with” && quote & >> pKeyPairs & quote into tCommandStr >> do tCommandstr >>put the result into tFoundIndex >>... >> >> A much more elegant (if probably no faster) solution is >> >> function myFindIndex pDataGrid, pKeyPairs >>— pKeyPairs is a comma delimited list such as >> “colname1,str1,colname2,str2,..” >> >> set the columnDelimiter to comma >> split pKeyPairs by column >> dispatch “FindIndex" to pDataGrid with pKeyPairs >>put the result into tFoundIndex >>... >> >> >> BTW, where did you find the source code for DataGrid handlers? I now see >> how one could write a FindIndices function to return all indices rather >> than just the first found … or even a general WHERE search :-) >> >> Neville Smythe >> >> >> >> >> ___ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > > > -- > On the first day, God created the heavens and the Earth > On the second day, God created the oceans. > On the third day, God put the animals on hold for a few hours, >and did a little diving. > And God said, "This is good." > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: FindIndex question
it's in the behavior of the dg you can also go digging through the OSS repo, if you like. On Sun, Mar 24, 2024 at 5:23 PM Neville Smythe via use-livecode < use-livecode@lists.runrev.com> wrote: > > > On 25 Mar 2024, at 3:00 am,Mike Kerner wrote: > > > > i don't know if you dove into the code, but it's too early to think about > > unpacking this, so here's the code: ... > > Thanks Mike > > While I was aware of the optional parameters feature of LC commands I have > never used it I so was unfamiliar with the syntax. The penny had never > dropped that the parameter list for a command is just an array, so > evidently you can actually send an array instead of a comma delimited list > > Which means that you can send FindIndex a single parameter pKeyPairsA > which is an array with alternating colName,searchStr values > > Setting up such an array is not particularly convenient for coding > however. My workaround had been to use a custom function hack > > function myFindIndex pDataGrid, pKeyPairs >— pKeyPairs is a comma delimited list such as > “colname1,str1,colname2,str2,..” > > replace comma with quote & comma & quote in pKeyPairs > put “dispatch FindIndex to” && pDataGrid && “with” && quote & > pKeyPairs & quote into tCommandStr > do tCommandstr >put the result into tFoundIndex >... > > A much more elegant (if probably no faster) solution is > > function myFindIndex pDataGrid, pKeyPairs >— pKeyPairs is a comma delimited list such as > “colname1,str1,colname2,str2,..” > > set the columnDelimiter to comma > split pKeyPairs by column > dispatch “FindIndex" to pDataGrid with pKeyPairs >put the result into tFoundIndex >... > > > BTW, where did you find the source code for DataGrid handlers? I now see > how one could write a FindIndices function to return all indices rather > than just the first found … or even a general WHERE search :-) > > Neville Smythe > > > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: FindIndex question
> On 25 Mar 2024, at 3:00 am,Mike Kerner wrote: > > i don't know if you dove into the code, but it's too early to think about > unpacking this, so here's the code: ... Thanks Mike While I was aware of the optional parameters feature of LC commands I have never used it I so was unfamiliar with the syntax. The penny had never dropped that the parameter list for a command is just an array, so evidently you can actually send an array instead of a comma delimited list Which means that you can send FindIndex a single parameter pKeyPairsA which is an array with alternating colName,searchStr values Setting up such an array is not particularly convenient for coding however. My workaround had been to use a custom function hack function myFindIndex pDataGrid, pKeyPairs — pKeyPairs is a comma delimited list such as “colname1,str1,colname2,str2,..” replace comma with quote & comma & quote in pKeyPairs put “dispatch FindIndex to” && pDataGrid && “with” && quote & pKeyPairs & quote into tCommandStr do tCommandstr put the result into tFoundIndex ... A much more elegant (if probably no faster) solution is function myFindIndex pDataGrid, pKeyPairs — pKeyPairs is a comma delimited list such as “colname1,str1,colname2,str2,..” set the columnDelimiter to comma split pKeyPairs by column dispatch “FindIndex" to pDataGrid with pKeyPairs put the result into tFoundIndex ... BTW, where did you find the source code for DataGrid handlers? I now see how one could write a FindIndices function to return all indices rather than just the first found … or even a general WHERE search :-) Neville Smythe ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: FindIndex question
i don't know if you dove into the code, but it's too early to think about unpacking this, so here's the code: *## pSearchA is array-valued index for accessing sDataArray* *## pSearchA[1] = key_1* *## pSearchA[2] = key_2* *command* FindIndex pKeyIndexA, pSearchString *--, ...* *-* *local* foundAMatch, theFoundIndex *local* i *local* theIndex *-* *repeat* for each key theIndex in sDataArray *## Developer can pass in multiple search strings to perform an AND search* *repeat* with i = 1 to the paramCount step 2 *if* sDataArray[theIndex][param(i)] is param(i+1) *then* *put* true into foundAMatch *else* *put* false into foundAMatch *end* *if* *## AND search didn't pan out. Move on to next index.* *if* not foundAMatch *then* *exit* *repeat* *end* *repeat* *if* foundAMatch *then* *put* theIndex into theFoundIndex *exit* *repeat* *end* *if* *end* *repeat* *return* max(0, theFoundIndex) *end* FindIndex On Sun, Mar 24, 2024 at 5:46 AM Neville Smythe via use-livecode < use-livecode@lists.runrev.com> wrote: > I am using FindIndex on a dataGrid > > dispatch "FindIndex" to tDataGrid with pKey, pSearchingString > > and I can pass multiple pKey, pSearchingString pairs such as > “col1",pSearchStr1,”col2”,pSearchStr2 as cited in the dictionary entry > > But there is also a rather cryptic note at the end of the FindIndex > dictionary entry > > Note that pKey can also be an array if you want to use array-valued > array indexing to locate pSearchingString. > > I took that to mean one could set up an array pKey with values such as > pKey[“col1”]=pSearchStr1, pKey[“col2”]=pSearchStr2 > and then just pass the pKey array. But that doesn’t work. > > Neither does using two indexed arrays pKey and pSearchStr with > pKey[1]=“col1”, pSearchStr[1]=pSearchStr1,pKey[2]=“col2”, > pSearchStr[2]=pSearchStr2 > > Anyone know what it does mean? > > > Neville Smythe > > > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
FindIndex question
I am using FindIndex on a dataGrid dispatch "FindIndex" to tDataGrid with pKey, pSearchingString and I can pass multiple pKey, pSearchingString pairs such as “col1",pSearchStr1,”col2”,pSearchStr2 as cited in the dictionary entry But there is also a rather cryptic note at the end of the FindIndex dictionary entry Note that pKey can also be an array if you want to use array-valued array indexing to locate pSearchingString. I took that to mean one could set up an array pKey with values such as pKey[“col1”]=pSearchStr1, pKey[“col2”]=pSearchStr2 and then just pass the pKey array. But that doesn’t work. Neither does using two indexed arrays pKey and pSearchStr with pKey[1]=“col1”, pSearchStr[1]=pSearchStr1,pKey[2]=“col2”, pSearchStr[2]=pSearchStr2 Anyone know what it does mean? Neville Smythe ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
