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
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 chunk
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 car
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
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 devi
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 retur
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
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
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
I
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
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...
11 matches
Mail list logo
