Compress/Decompress Inclustion?
In InfoWallet I store attachments as encrypted and compressed files on disk. When I build InfoWallet in LiveCode 9.6.1 and attempt to decompress and decrypt the file, I get an error that the data is not compressed. The file is definitely compressed. I’m manually selecting inclusions. Do I need to add compress and decompress as an Inclusion? If so, which Inclusion would it be? Here is the error: Executing at 2:45:53 PM on Saturday, October 3, 2020 Type: decompress: string is not compressed data Object: button 'ViewA' of card 'Records' of stack 'Bill Vlahos.ifw' Line: put decompress(vFile) into vFile Line Num: 16 Hint: mouseUp Thanks, Bill Vlahos ___ 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: Canvas Limited to 32767
I'm all for more freedom, but the RAM requirements make any practical use of extended coordinates a less trivial problem. Most programs handle this by paging. It may look like one contiguous region on screen, but as you're scrolling it's dumping chunks that fall out of view and rendering chunks coming into view, so the total viewable space is well within practical memory limits. The DataGrid shows one example of how to virtualize a scrollbar, using a non-scrolling group with a separate scrollbar, and some clever coding to make them work in sync. With that, you can do like other programmers do, paging in an out the parts you need when you need them. Only we get to do it in script. If done in the engine it's the same algo, which AFAIK is very different from how groups are buffered now. So "just" changing from 32k to 64k isn't as easy as putting the word "just" in front of it might make it seem. :) It would require the engine team to write a very different buffering algo, a lot of extra work for a few edge cases not handled by what's in place now. No doubt the team could do it, but I don't think it would be simple. And given the low ROI relative to other priorities, if it went into the work queue I wouldn't expect to see it for a long time. Maybe Mark Waddingham can chime in if I'm overestimating the difficulty, but I suspect scripting you own paging system with a virtualized scrollbar is something you could do yourself in a fraction of the time it would take to wait for it from the engine team. -- Richard Gaskin Fourth World Systems Ralph DiMola wrote: Richard, This design was done for one not to involve a lot of coding (App was free development but we get a cut of each sale and it has worked out well for us). Also there could be a reason to see the entire list but of course there are other ways to do this as not to hit the limit. As far as device memory is concerned I don't want to go to 2^31 but I am missing the cut by a couple thousand pixels. If we had 2^31 it would be up to the developer to keep the performance under control rather than apps breaking for 2 pixels over the limit. Ralph DiMola IT Director Evergreen Information Services rdimola at evergreeninfo.net -Original Message- From: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] On Behalf Of Richard Gaskin via use-livecode Sent: Tuesday, October 06, 2020 2:50 PM To: use-livecode at lists.runrev.com Cc: Richard Gaskin Subject: Re: Canvas Limited to 32767 Glad it's not the funky mobile field workaround. That's such a horrible experience for developers that even the act of documenting it should have been a red flag to go back and refine the field buffering for the few cases where that put-it-in-a-group recommendation is actually needed. In your case, you have a huuge canvas, with users expected to scroll a region about 32 feet. That's a lot of scrolling. So in addition to the memory hit of buffering such a large region (32767 * 32767 * 4 + whatever other overhead comes into play with buffering), in most layouts it would be a usability impairment to ask users to keep scrolling that much. So maybe the team could switch the address from 32 to 64, but it still leave us with the question: - Would a user have that much RAM? - Would the user be able to use such a large canvas without acquiring RSI? ;) I don't know your layout, but I do know you, and you're not the type to make things hard for users, so I'm assuming there's something about this uncommonly-large scrolling that fits well with the app's requirements. But what we do know is no monitor can show it all, so the content is already effectively paged into view as-needed. Could the content paging be provided through some other UI? For example, if those controls fit into logical groupings, might different sets of them be placed into separate physical groups, perhaps accessed via tabs or a list? If it's truly necessary to have one vast plane to hold everything, could you handle paging internally while still providing the appearance of a contiguous group, similar to how the DataGrid does it? -- Richard Gaskin Fourth World Systems Ralph DiMola wrote: > Desktop and mobile. It's a scrolling group with many sub-groups each > with 1 or more fields. Sometimes the height of the main group > 32767. > > It's the result of a proximity search and in dense areas users are > getting hosed by this limit. Customer is screaming (but don't they > always). > > Ralph DiMola > IT Director -Original Message- From: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] On Behalf Of Richard Gaskin via use-livecode Ralph DiMola wrote: > I just ran head first into this. Could someone explain why other than > moving from an int16 to an int32 this is such a challenge? This should > have been addressed during the refactoring of the engine. Is this for the weird recommended mobile workaround of putting
Re: backKey with DataGrid
This is a shot in the dark but this may have to do with the fact that once the dataGrid is in focus the template stack for the dataGrid becomes the recipient of your backKey message. Have you tried to add a backKey message to the template stack, and tweaking it to reference the button of the card in the original stack? Best regards Tore Nilsen > 7. okt. 2020 kl. 00:19 skrev Dan Friedman via use-livecode > : > > Here's a weird one... I have a card with a number of objects on it. There > is a button named "Back" which takes you back to card X. There is also a > dataGrid. In the mainStack script, I have a this backKey command: > > on backKey > //this is sent only on Android when the user presses the hardware "back" key > if there is a btn "Back" of this card then >send "mouseUp" to btn "Back" of this card in 1 tick > end if > > exit to top > end backKey > > When the card opens, and you tap the backKey (on an android device of > course), it works great! Now, if I scroll the dataGrid, the backKey message > fails. If I then tap any other control on the screen (not the dataGrid), > then the backKey message works again. This is true even if the dataGrid has > no data (ie.: set the dgData of grp "myDataGrid" to ""). > > I have verified that there is only 1 button named "Back" on the entire card > (including the template for the dataGrid). > > When I say the "backKey" message fails, what really happens is the statement > "if there is a btn "Back" of this card" does result as true, but the sending > of the "mouseUp" message isn't sent (or perhaps it's not received). Also, if > I just tap the "Back" button it does go back. > > Any ideas? > > -Dan > > ___ > 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
backKey with DataGrid
Here's a weird one... I have a card with a number of objects on it. There is a button named "Back" which takes you back to card X. There is also a dataGrid. In the mainStack script, I have a this backKey command: on backKey //this is sent only on Android when the user presses the hardware "back" key if there is a btn "Back" of this card then send "mouseUp" to btn "Back" of this card in 1 tick end if exit to top end backKey When the card opens, and you tap the backKey (on an android device of course), it works great! Now, if I scroll the dataGrid, the backKey message fails. If I then tap any other control on the screen (not the dataGrid), then the backKey message works again. This is true even if the dataGrid has no data (ie.: set the dgData of grp "myDataGrid" to ""). I have verified that there is only 1 button named "Back" on the entire card (including the template for the dataGrid). When I say the "backKey" message fails, what really happens is the statement "if there is a btn "Back" of this card" does result as true, but the sending of the "mouseUp" message isn't sent (or perhaps it's not received). Also, if I just tap the "Back" button it does go back. Any ideas? -Dan ___ 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: Canvas Limited to 32767
Richard, This design was done for one not to involve a lot of coding (App was free development but we get a cut of each sale and it has worked out well for us). Also there could be a reason to see the entire list but of course there are other ways to do this as not to hit the limit. As far as device memory is concerned I don't want to go to 2^31 but I am missing the cut by a couple thousand pixels. If we had 2^31 it would be up to the developer to keep the performance under control rather than apps breaking for 2 pixels over the limit. Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Richard Gaskin via use-livecode Sent: Tuesday, October 06, 2020 2:50 PM To: use-livecode@lists.runrev.com Cc: Richard Gaskin Subject: Re: Canvas Limited to 32767 Glad it's not the funky mobile field workaround. That's such a horrible experience for developers that even the act of documenting it should have been a red flag to go back and refine the field buffering for the few cases where that put-it-in-a-group recommendation is actually needed. In your case, you have a huuge canvas, with users expected to scroll a region about 32 feet. That's a lot of scrolling. So in addition to the memory hit of buffering such a large region (32767 * 32767 * 4 + whatever other overhead comes into play with buffering), in most layouts it would be a usability impairment to ask users to keep scrolling that much. So maybe the team could switch the address from 32 to 64, but it still leave us with the question: - Would a user have that much RAM? - Would the user be able to use such a large canvas without acquiring RSI? ;) I don't know your layout, but I do know you, and you're not the type to make things hard for users, so I'm assuming there's something about this uncommonly-large scrolling that fits well with the app's requirements. But what we do know is no monitor can show it all, so the content is already effectively paged into view as-needed. Could the content paging be provided through some other UI? For example, if those controls fit into logical groupings, might different sets of them be placed into separate physical groups, perhaps accessed via tabs or a list? If it's truly necessary to have one vast plane to hold everything, could you handle paging internally while still providing the appearance of a contiguous group, similar to how the DataGrid does it? -- Richard Gaskin Fourth World Systems Ralph DiMola wrote: > Desktop and mobile. It's a scrolling group with many sub-groups each > with 1 or more fields. Sometimes the height of the main group > 32767. > > It's the result of a proximity search and in dense areas users are > getting hosed by this limit. Customer is screaming (but don't they > always). > > Ralph DiMola > IT Director -Original Message- From: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] On Behalf Of Richard Gaskin via use-livecode Ralph DiMola wrote: > I just ran head first into this. Could someone explain why other than > moving from an int16 to an int32 this is such a challenge? This should > have been addressed during the refactoring of the engine. Is this for the weird recommended mobile workaround of putting a text field into a group just to have it scroll, or something else? -- Richard Gaskin Fourth World Systems ___ 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: Canvas Limited to 32767
Paul, I agree the it seems that 32767 would be more than enough but alas reality intrudes. On desktop you can easily get to the bottom and on mobile a few flicks will get you to the bottom. I use the same code(LC server) for the http html version and there is no problem there when the search returns an obscene number of results. Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Paul Dupuis via use-livecode Sent: Tuesday, October 06, 2020 2:39 PM To: use-livecode@lists.runrev.com Cc: Paul Dupuis Subject: Re: Canvas Limited to 32767 You would think with 32K px at 72px/inch being like 450 inches that the 32K limit would not be an issue, but I have run into it as well I have written a custom graph (like a bar graph for example sake) that is generally fine with most customer data. However, on one customer data set it started blowing up. It turns out that one of the bars was "huge" (an the order of 400k px) at the zoom level where they could see the details in the remaining bars. So, in this case the researchers wanted to "zoom" in on noise in a larger data set, causing that larger data to become huge in a graph. And yes, you can code in bounds limits and attaching labels to indicate a bar is out of bound or exceeds display area, etc., but I do agree that for a number of applications having a large drawing area would be a big improvement. On 10/6/2020 2:28 PM, Ralph DiMola via use-livecode wrote: > Desktop and mobile. It's a scrolling group with many sub-groups each > with 1 or more fields. Sometimes the height of the main group > 32767. > > It's the result of a proximity search and in dense areas users are > getting hosed by this limit. Customer is screaming (but don't they always). > > Ralph DiMola > IT Director > Evergreen Information Services > rdim...@evergreeninfo.net > > > -Original Message- > From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On > Behalf Of Richard Gaskin via use-livecode > Sent: Tuesday, October 06, 2020 2:01 PM > To: use-livecode@lists.runrev.com > Cc: Richard Gaskin > Subject: Re: Canvas Limited to 32767 > > Ralph DiMola wrote: > > > I just ran head first into this. Could someone explain why other > than > moving from an int16 to an int32 this is such a challenge? > This should > have been addressed during the refactoring of the engine. > > Is this for the weird recommended mobile workaround of putting a text > field into a group just to have it scroll, or something else? > > -- >Richard Gaskin >Fourth World Systems >Software Design and Development for the Desktop, Mobile, and the Web > >ambassa...@fourthworld.comhttp://www.FourthWorld.com > > > ___ > 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 ___ 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: Canvas Limited to 32767
Glad it's not the funky mobile field workaround. That's such a horrible experience for developers that even the act of documenting it should have been a red flag to go back and refine the field buffering for the few cases where that put-it-in-a-group recommendation is actually needed. In your case, you have a huuge canvas, with users expected to scroll a region about 32 feet. That's a lot of scrolling. So in addition to the memory hit of buffering such a large region (32767 * 32767 * 4 + whatever other overhead comes into play with buffering), in most layouts it would be a usability impairment to ask users to keep scrolling that much. So maybe the team could switch the address from 32 to 64, but it still leave us with the question: - Would a user have that much RAM? - Would the user be able to use such a large canvas without acquiring RSI? ;) I don't know your layout, but I do know you, and you're not the type to make things hard for users, so I'm assuming there's something about this uncommonly-large scrolling that fits well with the app's requirements. But what we do know is no monitor can show it all, so the content is already effectively paged into view as-needed. Could the content paging be provided through some other UI? For example, if those controls fit into logical groupings, might different sets of them be placed into separate physical groups, perhaps accessed via tabs or a list? If it's truly necessary to have one vast plane to hold everything, could you handle paging internally while still providing the appearance of a contiguous group, similar to how the DataGrid does it? -- Richard Gaskin Fourth World Systems Ralph DiMola wrote: > Desktop and mobile. It's a scrolling group with many sub-groups each > with 1 or more fields. Sometimes the height of the main group > 32767. > > It's the result of a proximity search and in dense areas users are > getting hosed by this limit. Customer is screaming (but don't they > always). > > Ralph DiMola > IT Director -Original Message- From: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] On Behalf Of Richard Gaskin via use-livecode Ralph DiMola wrote: > I just ran head first into this. Could someone explain why other than > moving from an int16 to an int32 this is such a challenge? This should > have been addressed during the refactoring of the engine. Is this for the weird recommended mobile workaround of putting a text field into a group just to have it scroll, or something else? -- Richard Gaskin Fourth World Systems ___ 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: Canvas Limited to 32767
You would think with 32K px at 72px/inch being like 450 inches that the 32K limit would not be an issue, but I have run into it as well I have written a custom graph (like a bar graph for example sake) that is generally fine with most customer data. However, on one customer data set it started blowing up. It turns out that one of the bars was "huge" (an the order of 400k px) at the zoom level where they could see the details in the remaining bars. So, in this case the researchers wanted to "zoom" in on noise in a larger data set, causing that larger data to become huge in a graph. And yes, you can code in bounds limits and attaching labels to indicate a bar is out of bound or exceeds display area, etc., but I do agree that for a number of applications having a large drawing area would be a big improvement. On 10/6/2020 2:28 PM, Ralph DiMola via use-livecode wrote: Desktop and mobile. It's a scrolling group with many sub-groups each with 1 or more fields. Sometimes the height of the main group > 32767. It's the result of a proximity search and in dense areas users are getting hosed by this limit. Customer is screaming (but don't they always). Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Richard Gaskin via use-livecode Sent: Tuesday, October 06, 2020 2:01 PM To: use-livecode@lists.runrev.com Cc: Richard Gaskin Subject: Re: Canvas Limited to 32767 Ralph DiMola wrote: > I just ran head first into this. Could someone explain why other than > moving from an int16 to an int32 this is such a challenge? This should > have been addressed during the refactoring of the engine. Is this for the weird recommended mobile workaround of putting a text field into a group just to have it scroll, or something else? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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 ___ 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: Canvas Limited to 32767
Desktop and mobile. It's a scrolling group with many sub-groups each with 1 or more fields. Sometimes the height of the main group > 32767. It's the result of a proximity search and in dense areas users are getting hosed by this limit. Customer is screaming (but don't they always). Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Richard Gaskin via use-livecode Sent: Tuesday, October 06, 2020 2:01 PM To: use-livecode@lists.runrev.com Cc: Richard Gaskin Subject: Re: Canvas Limited to 32767 Ralph DiMola wrote: > I just ran head first into this. Could someone explain why other than > moving from an int16 to an int32 this is such a challenge? This should > have been addressed during the refactoring of the engine. Is this for the weird recommended mobile workaround of putting a text field into a group just to have it scroll, or something else? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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: Canvas Limited to 32767
Ralph DiMola wrote: > I just ran head first into this. Could someone explain why other than > moving from an int16 to an int32 this is such a challenge? This should > have been addressed during the refactoring of the engine. Is this for the weird recommended mobile workaround of putting a text field into a group just to have it scroll, or something else? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Canvas Limited to 32767
I just ran head first into this. Could someone explain why other than moving from an int16 to an int32 this is such a challenge? This should have been addressed during the refactoring of the engine. Inquiring minds want to know. Thanks for any info on this. Now I have some refactoring to do... Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net ___ 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
