Re: UI performance and large data set in Table Object
To be frank, Rev's native table object leaves an awful lot to be desired. Quite a few people on this list ended up writing their own table object instead. I wrote one with resizable columns and column-click sorting that was based on a normal scrolling field. It was lightening fast with thousands of rows. Chipp has made his table control publicly available: http://www.altuit.com/webs/altuit2/RunRevArchived/Archives.htm and look for 'altFldHeader Control'. It may well turn out that this serves your needs better than Rev's table object. Bernard mfstuart wrote: I also tried the Scrolling Field and compared it to the Table Field, using 20,844 lines - big difference, where the Scrolling Field won in it's performance of no degradation of stack resize. But I've never used this object before, because I lose the formatting of columnar presentation. If I use this object, is there a way to set it to columnar appearance? And isn't it when you check the table property for this object, it changes everything back to a Table Field? -- View this message in context: http://www.nabble.com/UI-performance-and-large-data-set-in-Table-Object-tp15618647p15629164.html Sent from the Revolution - User mailing list archive at Nabble.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: UI performance and large data set in Table Object
Hi Mark, use scrolling field object with vgrid and hgrid set to true (table to false), so you will get it formatted correctly without all the overheads of the table object. I always use this when I need table and it for me handles a few thousand records without any slowing downs. One more option would be to play with LIMIT and OFFSET in SQL SELECT's and display only parts of the query that you want to. All the best Viktoras ___ 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: UI performance and large data set in Table Object
Hi, Hi Sarah, That sounds promising, especially reading prior threads on the same custom property concept. The data was there already. I actually MOVED it to custom properties rather than duplicating the data, so the overhead was no worse than it had been and quite acceptable. The stack ended up at about 6 MB. The data is not stored forever, it just builds up over 1 - 2 weeks, then gets cleared and the process starts again. I did use the same concept for an old project. During development, all of a project Datas where stored in a folder on an Intranet site, to be shared by multiple computers. When everything works, and for security, administration and others reasons I forgot, I put the contents of a folder in a stack, no widget, only an empty stack, with no scripts and only customs properties. One stack contains all the Datas plus Log information plus extras time Datas,... To choose a project, the user has to choose a file, stored wherever he feels on his disk. These stacks could be more than 10 Mb, storing, text, binary datas, logs, images, I did change the extension of these stacks too... so the users could see their projects as a one file; they like it. Another thing to say that choosing this architecture, the development was short with almost no debug process ! And if you come from another software planet, customs properties are only associative arrays, no more really. And the last but not the least, it was before 2000, and, at this time, I got so many clever and good answers from this list... :-) HTH, Have a nice day, Thierry ___ 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: UI performance and large data set in Table Object
mfstuart wrote: As I mentioned in my previous listing, 20, 30, or 5 lines can be found, depends on the users search criteria. My example was 20,844 lines). The record length for the table is 255 (counting up the SQL definition lengths for all columns) On the stack I'm only using 8 of the 13 columns from the SQL table. The record length for the Table Field then is 200. I also tried the Scrolling Field and compared it to the Table Field, using 20,844 lines - big difference, where the Scrolling Field won in it's performance of no degradation of stack resize. But I've never used this object before, because I lose the formatting of columnar presentation. If I use this object, is there a way to set it to columnar appearance? The field object was the key to the recipe I provided in my earlier post, but when I wrote that I forgot to specify Any text container controls other than what the IDE calls a 'Table Object'. :) The other ingredients in my recipe were to set its hGrid and vGrid properties. Once you do that, you've just made an engine-native table field. I don't use the Rev IDE myself, so I've never had occasion to use it's Table Object (I still use the old IDE from before the acquisition, MetaCard), so I can't guess what it's doing that would eat so much time. But apparently some of the extra properties they set in it trigger a lot of other scripts in their libraries. Does anyone here know what the scripts driving Rev's Table Object are doing that would require so much processing during resizing? While there may be some room to optimize some of the scripts in the Rev IDE, I have a *lot* of confidence in the Rev engine. Glad to see you've found a solution with it that performs well. Know the engine. Trust the engine. Use the engine. :) -- 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: UI performance and large data set in Table Object
Mark, you might store the data from the database in a custom property of the table field, and only show as much data as will fit in the field at it's current size. You'd have to write your own scrolling routines to update the display, but it can be done. Best, Mark On 21 Feb 2008, at 19:04, mfstuart wrote: Hi All, I have a question about large data sets (thousands of lines) in a table object and the slowing down of the UI performance, especially on resizing the stack. My application interfaces to an MS SQL 2000 database via ODBC. No problem there. The SQL table I have has over half a million records in it, and this grows all the time. Potentially, the user could return all records, which would take a while to load them all. But I've created the interface to allow the user to return a smaller record set. This can be alot of records - 10, 30, 40, 5 thousand or more, or just a few hundred. It depends on how the user searches the database. Now when large record sets are returned from a search, the UI (user interface) slows down, especially when resizing the stack to see more records in the table object. When resizing with no records, the UI is performs normally with fast resizing. Q: has any one seen this before? And if so, how do you handle the drop in UI performance? Thanx, Mark Stuart -- View this message in context: http://www.nabble.com/UI-performance- and-large-data-set-in-Table-Object-tp15618647p15618647.html Sent from the Revolution - User mailing list archive at Nabble.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: UI performance and large data set in Table Object
--- mfstuart [EMAIL PROTECTED] wrote: Hi All, I have a question about large data sets (thousands of lines) in a table object and the slowing down of the UI performance, especially on resizing the stack. My application interfaces to an MS SQL 2000 database via ODBC. No problem there. The SQL table I have has over half a million records in it, and this grows all the time. Potentially, the user could return all records, which would take a while to load them all. But I've created the interface to allow the user to return a smaller record set. This can be alot of records - 10, 30, 40, 5 thousand or more, or just a few hundred. It depends on how the user searches the database. Now when large record sets are returned from a search, the UI (user interface) slows down, especially when resizing the stack to see more records in the table object. When resizing with no records, the UI is performs normally with fast resizing. Q: has any one seen this before? And if so, how do you handle the drop in UI performance? Thanx, Mark Stuart Hi Mark, The problem is two-fold: it's a lot of data that has to go through some pipe before it arrives in Revolution, and Revolution then has to process and format a lot of that to determine what to actually display on screen, recalculate the size of the scrollbar, etc. For a project where it was taking a lot of time before the user saw anything, I decided to take a different approach: rather than rely on a single call to revdb_querylist()/revDataFromQuery(), to use a result set cursor and a 'send in time' construct to fetch 20 records at a time. This approach allows the user interface to remain responsive, and the user can see the table filling up as more data comes in. It also means you can cancel the rest of the data download as soon as the user finds the record he wants, or decides to make a different selection. It looks something like this: ## global gConnectionID local sFetchMsgID, sCursorID, sColumnCount on mouseUp CancelFetchTimer put SELECT * FROM Customers into tQuery put revdb_query(gConnectionID, tQuery) into sCursorID if sCursorID is not a number then answer error sCursorID exit mouseUp end if put revDatabaseColumnCount(sCursorID) into sColumnCount put empty into field QueryResults send FetchNext20Records to me in 0 milliseconds put the result into sFetchMsgID end mouseUp on FetchNext20Records put false into tStopFlag repeat 20 times repeat with tColumn = 1 to sColumnCount put revDatabaseColumnNumbered(sCursorID, tColumn) \ tab after tNextPart end repeat put return into char -1 of tNextPart put revCurrentRecordIsLast(sCursorID) into tStopFlag if tStopFlag then delete char -1 of tNextPart exit repeat end if end repeat put tNextPart after field QueryResults if tStopFlag then put empty into sFetchMsgID else send FetchNext20Records to me in 100 milliseconds put the result into sFetchMsgID end if end FetchNext20Records on CancelFetchTimer if sFetchMsgID is not empty then cancel sFetchMsgID put empty into sFetchMsgID end if end CancelFetchTimer ## This is all off the top of my head, so beware of typos. Hope this helped, Jan Schenkel. Quartam Reports PDF Library for Revolution http://www.quartam.com = As we grow older, we grow both wiser and more foolish at the same time. (La Rochefoucauld) Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ 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: UI performance and large data set in Table Object
Jan Schenkel wrote: Now when large record sets are returned from a search, the UI (user interface) slows down, especially when resizing the stack to see more records in the table object. When resizing with no records, the UI is performs normally with fast resizing. ... The problem is two-fold: it's a lot of data that has to go through some pipe before it arrives in Revolution, and Revolution then has to process and format a lot of that to determine what to actually display on screen, recalculate the size of the scrollbar, etc. FWIW, I did some subjective tests with scrolling large amounts of data in Rev vs. Word, Excel, and others. Rev outperformed them all, quite noticeably. So if it seems slow, try the same size data anywhere else. Sometimes a lot of data just takes a long time to redraw. Fortunately the user will likely resize a window infrequently. -- 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: UI performance and large data set in Table Object
--- Richard Gaskin [EMAIL PROTECTED] wrote: Jan Schenkel wrote: Now when large record sets are returned from a search, the UI (user interface) slows down, especially when resizing the stack to see more records in the table object. When resizing with no records, the UI is performs normally with fast resizing. ... The problem is two-fold: it's a lot of data that has to go through some pipe before it arrives in Revolution, and Revolution then has to process and format a lot of that to determine what to actually display on screen, recalculate the size of the scrollbar, etc. FWIW, I did some subjective tests with scrolling large amounts of data in Rev vs. Word, Excel, and others. Rev outperformed them all, quite noticeably. So if it seems slow, try the same size data anywhere else. Sometimes a lot of data just takes a long time to redraw. Fortunately the user will likely resize a window infrequently. -- Richard Gaskin Managing Editor, revJournal Excellent point, Richard - Revolution is indeed much faster than the MS behemoths. Combining Mark's advice of caching the data in an off-screen buffer with the 'fake-threaded' chunked download approach, allows us to squeeze every drop of performance out of our favourite development tool... Jan Schenkel. Quartam Reports PDF Library for Revolution http://www.quartam.com = As we grow older, we grow both wiser and more foolish at the same time. (La Rochefoucauld) Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ 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: UI performance and large data set in Table Object
I haven't tried storing data in a custom property as yet, but wouldn't that render the same lack of performance behavior, where putting the data into a stack of the UI? Mark Stuart masmit wrote: Mark, you might store the data from the database in a custom property of the table field, and only show as much data as will fit in the field at it's current size. You'd have to write your own scrolling routines to update the display, but it can be done. Best, Mark On 21 Feb 2008, at 19:04, mfstuart wrote: Hi All, I have a question about large data sets (thousands of lines) in a table object and the slowing down of the UI performance, especially on resizing the stack. My application interfaces to an MS SQL 2000 database via ODBC. No problem there. The SQL table I have has over half a million records in it, and this grows all the time. Potentially, the user could return all records, which would take a while to load them all. But I've created the interface to allow the user to return a smaller record set. This can be alot of records - 10, 30, 40, 5 thousand or more, or just a few hundred. It depends on how the user searches the database. Now when large record sets are returned from a search, the UI (user interface) slows down, especially when resizing the stack to see more records in the table object. When resizing with no records, the UI is performs normally with fast resizing. Q: has any one seen this before? And if so, how do you handle the drop in UI performance? Thanx, Mark Stuart -- View this message in context: http://www.nabble.com/UI-performance- and-large-data-set-in-Table-Object-tp15618647p15618647.html Sent from the Revolution - User mailing list archive at Nabble.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 -- View this message in context: http://www.nabble.com/UI-performance-and-large-data-set-in-Table-Object-tp15618647p15622814.html Sent from the Revolution - User mailing list archive at Nabble.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: UI performance and large data set in Table Object
On Fri, Feb 22, 2008 at 9:21 AM, mfstuart [EMAIL PROTECTED] wrote: I haven't tried storing data in a custom property as yet, but wouldn't that render the same lack of performance behavior, where putting the data into a stack of the UI? No, because the engine doesn't have to think about how to display your data, it's just storing whatever you put in there. I got involved in a project were data was being stored in fields on another card, so not even visible. The amount of data was getting quite large, about 40,000 lines in each field. When I changed it to storing the data in custom properties, the speed of adding new data points dropped from around 3 seconds to about 5 ticks! Cheers, Sarah ___ 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: UI performance and large data set in Table Object
Hi Richard, My day job is a software engineer, using another software development tool - eDeveloper. The product we build (CRM) is for enterprise sized companies, working on large amounts of SQL data. eDeveloper does not produce this UI lack of performance during runtime. This is how I noticed the difference in behavior. As far as Excel and Rev, both load the data into memory, which I would assume then declines the available resources, causing the issue at hand. Whereas the table object in our software is reading the data continually (??) from the database, caching when needed, so the lack of performance is never noticed. Mark Stuart Richard Gaskin wrote: Jan Schenkel wrote: Now when large record sets are returned from a search, the UI (user interface) slows down, especially when resizing the stack to see more records in the table object. When resizing with no records, the UI is performs normally with fast resizing. ... The problem is two-fold: it's a lot of data that has to go through some pipe before it arrives in Revolution, and Revolution then has to process and format a lot of that to determine what to actually display on screen, recalculate the size of the scrollbar, etc. FWIW, I did some subjective tests with scrolling large amounts of data in Rev vs. Word, Excel, and others. Rev outperformed them all, quite noticeably. So if it seems slow, try the same size data anywhere else. Sometimes a lot of data just takes a long time to redraw. Fortunately the user will likely resize a window infrequently. -- 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 -- View this message in context: http://www.nabble.com/UI-performance-and-large-data-set-in-Table-Object-tp15618647p15623495.html Sent from the Revolution - User mailing list archive at Nabble.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: UI performance and large data set in Table Object
Hi Jan, Where the reading of the SQL data and loading into a table object is not quite the issue here, never the less, it is an issue I haven't dealt with as yet in this application. But I will try your approach, copying your script to an archive for future pondering. This current issue is the resizing of the stack AFTER the data has loaded to the table object. When resizing, it is very slow and cumbersome and even produces delays to the resized stack dimensions. Mark Stuart Jan Schenkel wrote: --- mfstuart [EMAIL PROTECTED] wrote: Hi All, I have a question about large data sets (thousands of lines) in a table object and the slowing down of the UI performance, especially on resizing the stack. My application interfaces to an MS SQL 2000 database via ODBC. No problem there. The SQL table I have has over half a million records in it, and this grows all the time. Potentially, the user could return all records, which would take a while to load them all. But I've created the interface to allow the user to return a smaller record set. This can be alot of records - 10, 30, 40, 5 thousand or more, or just a few hundred. It depends on how the user searches the database. Now when large record sets are returned from a search, the UI (user interface) slows down, especially when resizing the stack to see more records in the table object. When resizing with no records, the UI is performs normally with fast resizing. Q: has any one seen this before? And if so, how do you handle the drop in UI performance? Thanx, Mark Stuart Hi Mark, The problem is two-fold: it's a lot of data that has to go through some pipe before it arrives in Revolution, and Revolution then has to process and format a lot of that to determine what to actually display on screen, recalculate the size of the scrollbar, etc. For a project where it was taking a lot of time before the user saw anything, I decided to take a different approach: rather than rely on a single call to revdb_querylist()/revDataFromQuery(), to use a result set cursor and a 'send in time' construct to fetch 20 records at a time. This approach allows the user interface to remain responsive, and the user can see the table filling up as more data comes in. It also means you can cancel the rest of the data download as soon as the user finds the record he wants, or decides to make a different selection. It looks something like this: ## global gConnectionID local sFetchMsgID, sCursorID, sColumnCount on mouseUp CancelFetchTimer put SELECT * FROM Customers into tQuery put revdb_query(gConnectionID, tQuery) into sCursorID if sCursorID is not a number then answer error sCursorID exit mouseUp end if put revDatabaseColumnCount(sCursorID) into sColumnCount put empty into field QueryResults send FetchNext20Records to me in 0 milliseconds put the result into sFetchMsgID end mouseUp on FetchNext20Records put false into tStopFlag repeat 20 times repeat with tColumn = 1 to sColumnCount put revDatabaseColumnNumbered(sCursorID, tColumn) \ tab after tNextPart end repeat put return into char -1 of tNextPart put revCurrentRecordIsLast(sCursorID) into tStopFlag if tStopFlag then delete char -1 of tNextPart exit repeat end if end repeat put tNextPart after field QueryResults if tStopFlag then put empty into sFetchMsgID else send FetchNext20Records to me in 100 milliseconds put the result into sFetchMsgID end if end FetchNext20Records on CancelFetchTimer if sFetchMsgID is not empty then cancel sFetchMsgID put empty into sFetchMsgID end if end CancelFetchTimer ## This is all off the top of my head, so beware of typos. Hope this helped, Jan Schenkel. Quartam Reports PDF Library for Revolution http://www.quartam.com = As we grow older, we grow both wiser and more foolish at the same time. (La Rochefoucauld) Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ 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 -- View this message in context: http://www.nabble.com/UI-performance-and-large-data-set-in-Table-Object-tp15618647p15623100.html Sent from the Revolution - User mailing list archive at Nabble.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: UI performance and large data set in Table Object
mfstuart wrote: My day job is a software engineer, using another software development tool - eDeveloper. The product we build (CRM) is for enterprise sized companies, working on large amounts of SQL data. eDeveloper does not produce this UI lack of performance during runtime. This is how I noticed the difference in behavior. As far as Excel and Rev, both load the data into memory, which I would assume then declines the available resources, causing the issue at hand. Whereas the table object in our software is reading the data continually (??) from the database, caching when needed, so the lack of performance is never noticed. Rev fields are smartly buffered and tend to redraw faster than any other app on my hard drive. If you're seeing unusually slow redraws it may be related to Rev libraries rather than the engine itself. Try this: Make a new stack, add a field, turn on the field's hGrid and vGrid properties, and dump an equivalent amount of data into it. To handle the resize, use this rather than Rev's Geometry Manager: on resizeStack x,y set the rect of fld 1 to 20,20,x-20,y-20 end resizeStack If Rev is as efficient as I think it is, that test should show a pretty smooth update. If not we can look into it more deeply. -- 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: UI performance and large data set in Table Object
Hi Richard, I did as you suggested and copied 8 columns of data (20,844 lines) into this new stack. Just a table object on the card - no scripts (except your 'on resizeStack' in the stack), no other objects. resize result: same slow behavior :( Any other thoughts on that? Mark Stuart Richard Gaskin wrote: mfstuart wrote: My day job is a software engineer, using another software development tool - eDeveloper. The product we build (CRM) is for enterprise sized companies, working on large amounts of SQL data. eDeveloper does not produce this UI lack of performance during runtime. This is how I noticed the difference in behavior. As far as Excel and Rev, both load the data into memory, which I would assume then declines the available resources, causing the issue at hand. Whereas the table object in our software is reading the data continually (??) from the database, caching when needed, so the lack of performance is never noticed. Rev fields are smartly buffered and tend to redraw faster than any other app on my hard drive. If you're seeing unusually slow redraws it may be related to Rev libraries rather than the engine itself. Try this: Make a new stack, add a field, turn on the field's hGrid and vGrid properties, and dump an equivalent amount of data into it. To handle the resize, use this rather than Rev's Geometry Manager: on resizeStack x,y set the rect of fld 1 to 20,20,x-20,y-20 end resizeStack If Rev is as efficient as I think it is, that test should show a pretty smooth update. If not we can look into it more deeply. -- 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 -- View this message in context: http://www.nabble.com/UI-performance-and-large-data-set-in-Table-Object-tp15618647p15625188.html Sent from the Revolution - User mailing list archive at Nabble.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: UI performance and large data set in Table Object
mfstuart wrote: I did as you suggested and copied 8 columns of data (20,844 lines) into this new stack. Just a table object on the card - no scripts (except your 'on resizeStack' in the stack), no other objects. resize result: same slow behavior :( Any other thoughts on that? How much data is in the field? (How many lines, and average length of the lines) -- 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: UI performance and large data set in Table Object
Mark, Are you using a table object, or a regular scrolling field with the hGrid and vGrid properties turned on? The former is an emulated control which may slow down significantly, while the latter should be significantly faster. In the past, I've managed to put data on the order of 20 columns / 100,000 rows into regular fields. I don't recall how snappy things were, but I don't remember having problems. HTH, Brian Hi Richard, I did as you suggested and copied 8 columns of data (20,844 lines) into this new stack. Just a table object on the card - no scripts (except your 'on resizeStack' in the stack), no other objects. resize result: same slow behavior :( Any other thoughts on that? Mark Stuart ___ 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: UI performance and large data set in Table Object
Hi Sarah, That sounds promising, especially reading prior threads on the same custom property concept. (A thought on this concept of copying data to a custom property - wouldn't it consume large amounts of the users computer memory/resources?) But this is a multi-user application, where many users will be searching, updating, deleting, and adding records into the SQL database thru this Rev app. It's not a read-only application. I think if it was, the custom property could be worth looking at. Mark Stuart Sarah Reichelt-2 wrote: On Fri, Feb 22, 2008 at 9:21 AM, mfstuart [EMAIL PROTECTED] wrote: I haven't tried storing data in a custom property as yet, but wouldn't that render the same lack of performance behavior, where putting the data into a stack of the UI? No, because the engine doesn't have to think about how to display your data, it's just storing whatever you put in there. I got involved in a project were data was being stored in fields on another card, so not even visible. The amount of data was getting quite large, about 40,000 lines in each field. When I changed it to storing the data in custom properties, the speed of adding new data points dropped from around 3 seconds to about 5 ticks! Cheers, Sarah ___ 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 -- View this message in context: http://www.nabble.com/UI-performance-and-large-data-set-in-Table-Object-tp15618647p15625210.html Sent from the Revolution - User mailing list archive at Nabble.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: UI performance and large data set in Table Object
Hi Sarah, That sounds promising, especially reading prior threads on the same custom property concept. (A thought on this concept of copying data to a custom property - wouldn't it consume large amounts of the users computer memory/resources?) The data was there already. I actually MOVED it to custom properties rather than duplicating the data, so the overhead was no worse than it had been and quite acceptable. The stack ended up at about 6 MB. The data is not stored forever, it just builds up over 1 - 2 weeks, then gets cleared and the process starts again. But this is a multi-user application, where many users will be searching, updating, deleting, and adding records into the SQL database thru this Rev app. It's not a read-only application. I think if it was, the custom property could be worth looking at. Mark Stuart I still think if you do a query and load the entire result into a custom property, then show only portions of this data at a time in a field, you will have the best of both worlds - minimizing the number of trips to the server and minimizing the display times. Cheers, Sarah Sarah Reichelt-2 wrote: On Fri, Feb 22, 2008 at 9:21 AM, mfstuart [EMAIL PROTECTED] wrote: I haven't tried storing data in a custom property as yet, but wouldn't that render the same lack of performance behavior, where putting the data into a stack of the UI? No, because the engine doesn't have to think about how to display your data, it's just storing whatever you put in there. I got involved in a project were data was being stored in fields on another card, so not even visible. The amount of data was getting quite large, about 40,000 lines in each field. When I changed it to storing the data in custom properties, the speed of adding new data points dropped from around 3 seconds to about 5 ticks! Cheers, Sarah ___ 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: UI performance and large data set in Table Object
Hi Richard, I'm at home now. looking at this... As I mentioned in my previous listing, 20, 30, or 5 lines can be found, depends on the users search criteria. My example was 20,844 lines). The record length for the table is 255 (counting up the SQL definition lengths for all columns) On the stack I'm only using 8 of the 13 columns from the SQL table. The record length for the Table Field then is 200. I also tried the Scrolling Field and compared it to the Table Field, using 20,844 lines - big difference, where the Scrolling Field won in it's performance of no degradation of stack resize. But I've never used this object before, because I lose the formatting of columnar presentation. If I use this object, is there a way to set it to columnar appearance? And isn't it when you check the table property for this object, it changes everything back to a Table Field? Thanx, Mark Stuart Richard Gaskin wrote: mfstuart wrote: I did as you suggested and copied 8 columns of data (20,844 lines) into this new stack. Just a table object on the card - no scripts (except your 'on resizeStack' in the stack), no other objects. resize result: same slow behavior :( Any other thoughts on that? How much data is in the field? (How many lines, and average length of the lines) -- 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 -- View this message in context: http://www.nabble.com/UI-performance-and-large-data-set-in-Table-Object-tp15618647p15626387.html Sent from the Revolution - User mailing list archive at Nabble.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: UI performance and large data set in Table Object
Table appearance in a scrolling field can also be accomplished just using tabs. Check out the table pulldown on the object inspector uncheck table object check hgrid and or vgrid grid lines color can be subtle If I use this object, is there a way to set it to columnar appearance? And isn't it when you check the table property for this object, it changes everything back to a Table Field? Thanx, Mark Stuart -- 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
