Bernd wrote:
>>From the dictionary p 59
>
> Maximum length of a LINE in a field:
>
> 65,536 characters storage
> No more than 32,786 pixels wide for display
I had thought there had been some work on that in recent years, but I
dug up the bug report and it seems it's been "hibernated":
On Thu, Nov 29, 2018 at 3:42 AM Niggemann, Bernd via use-livecode <
use-livecode@lists.runrev.com> wrote:
> From the dictionary p 59
>
>
> Maximum length of a LINE in a field:
>
> 65,536 characters storage
> No more than 32,786 pixels wide for display
>
> Kind regards
> Bernd
>
I guess I should
>From the dictionary p 59
Maximum length of a LINE in a field:
65,536 characters storage
No more than 32,786 pixels wide for display
Kind regards
Bernd
From: Geoff Canyon
I just checked, and (LC 8 on a Mac) indeed fields fail beyond a certain
width/character limit/???
This:
on mouseUp
I just checked, and (LC 8 on a Mac) indeed fields fail beyond a certain
width/character limit/???
This:
on mouseUp
repeat with i = 1 to 1
put char -10 to -1 of ("aa" & i & " ") after x
end repeat
put x into fld 1
end mouseUp
results in a field that scrolls right only
dunbarxx wrote:
> What really needs to happen is that the DG or table field visual
> display is loaded under script control. So the idea of jumping from
> a display of columns 1-10 over to 6000-6010 is managed live, using
> the scrollbarDrag message as the thumb is moved.
Yes, that's exactly
On Mon, Nov 26, 2018 at 3:08 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Try the field object.
>
Not that this couldn't be worked around, but isn't a field limited in the
width of what it can display? i.e. put a single line 100,000 characters
long into an
On 27/11/2018 18:34, Richard Gaskin via use-livecode wrote:
The existing field object does a fine job buffering for smooth
scrolling of just about any text of practical length. Logically, the
limit of field contents is about 4GB (UINT4), but in practical terms
other memory needs may not
What really needs to happen is that the DG or table field visual display is
loaded under script control. So the idea of jumping from a display of
columns 1-10 over to 6000-6010 is managed live, using the scrollbarDrag
message as the thumb is moved. What the user sees during that process is a
Alex Tweedly wrote:
> On 25/11/2018 23:04, Richard Gaskin via use-livecode wrote:
>>
>> This limitation may have been eliminated, or close to eliminated,
>> with the field object. And now that fields have column-independent
>> alignment, it's rare that there's ever a need to replace that one
>>
On 25/11/2018 23:04, Richard Gaskin via use-livecode wrote:
This limitation may have been eliminated, or close to eliminated, with
the field object. And now that fields have column-independent
alignment, it's rare that there's ever a need to replace that one
object with a thousand-object
correction set the dgtext. Stupid spell correct.
Bob S
> On Nov 26, 2018, at 16:06 , Bob Sneidar via use-livecode
> wrote:
>
> Also, I was concerned because I didn't just fail to set the detect
___
use-livecode mailing list
That makes sense. Anyone working with this much data should probably build in
their own limits into the data they put into the grid. I know I will.
Bob S
> On Nov 26, 2018, at 15:17 , hh via use-livecode
> wrote:
>
> The limit of LC is not the sky but the 65535-limit
> for coordinates of
I read it. :-) My original question was simply, how many columns can a datagrid
have? In other words is there a limit? The reason it mattered to me at the time
was because I was importing a csv file with a lot of columns and it was easier
for me to set the dgProp ["columns"] to the first line
The limit of LC is not the sky but the 65535-limit
for coordinates of every object.
A line width can't be longer than 65535 pixels.
And if you have columns with a width of 11 pixels
each, then the right of column 5958 is 65538 what
is "off-limits".
___
Dunbarxx wrote:
> It is certainly possible that one might need an enormous DG or table
> field.
> It never happens that one must view such a beast all at once, or even
> a large part of it; that is not the issue. The point is that one
> cannot have such a control at all, and that seems unfair.
All:
It is certainly possible that one might need an enormous DG or table field.
It never happens that one must view such a beast all at once, or even a
large part of it; that is not the issue. The point is that one cannot have
such a control at all, and that seems unfair.
If one is looking at
For me the issue was converting a csv file exported from a copier. The csv file
has a LOT of columns (page counts for virtually everything and paper type black
and color the copier is capable, including scans, fax etc.) In the end I
decided to not use that file format and instead use the
That wasn't the issue. The issue was, how many columns before noticeable
decline in performance, and eventually death for the datagrid.
Bob S
> On Nov 21, 2018, at 13:27 , JJS via use-livecode
> wrote:
>
> what the h*ll you're going to do with 1500 columns?
>
> who's gonna work with that?
Geoff Canyon wrote:
> On Fri, Nov 23, 2018 at 4:38 PM Richard Gaskin wrote:
>
>> Geoff Canyon wrote:
>>
>> > It's not relevant to the current discussion, but wy back when,
>> > I worked with a guy who had created some monster spreadsheets in
>> > Excel with something like 9,000 columns. It
I don't remember what-all he did with it, but FileMaker proved to be
remarkably resilient pretty much no matter what he threw at it. The one
limitation back then was that a given file couldn't be more than 32MB(!).
On Fri, Nov 23, 2018 at 4:38 PM Richard Gaskin via use-livecode <
Geoff Canyon wrote:
> It's not relevant to the current discussion, but wy back when, I
> worked with a guy who had created some monster spreadsheets in Excel
> with something like 9,000 columns. It was working, but it was
> incredibly slow -- this was running on 68k Macs. Not expecting
>
well it's incredible big!
Yes Excell and outlook too can being very slow, on my job i have a
laptop from this year(lenovo) and it's running office 360, it's terrible
slow. But...it could also be due to the rest of the shitty software we
have to use like Labware(that's really crying and a pain
It's not relevant to the current discussion, but wy back when, I worked
with a guy who had created some monster spreadsheets in Excel with
something like 9,000 columns. It was working, but it was incredibly slow --
this was running on 68k Macs. Not expecting success, I suggested he give
you mean like this one:
https://www.legamaster.com/products/product/interactive-products/e-screen-interactive-touch-monitors/ptx-9800uhd-e-screen-8713797081610/?no_cache=1=158c87c7f0527df039ce11bc76eae9ab
But who can cope with 1500 columns, most people would stop and lost
track before
hahaha!...It never occured to me that people would have such large numbers
of columns ...it sounds like lots of fun. what is the data?
alsowondering .if there is another way. would a graph database
help?
On Wed, Nov 21, 2018 at 4:39 PM dunbarxx via use-livecode <
People with wide monitors?
--
Sent from:
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
what the h*ll you're going to do with 1500 columns?
who's gonna work with that?
Op 21-11-2018 om 17:08 schreef dunbarxx via use-livecode:
I tested with a table field. It can hold far many more columns, but it, too,
will go haywire if the tabStops are wide and the number of columns exceeds
I tested with a table field. It can hold far many more columns, but it, too,
will go haywire if the tabStops are wide and the number of columns exceeds
about 1500.
I was surprised that the number of columns matters. Certainly they are not
all drawn at once, but rather "exposed" based on internal
I had set the dgProp ["columns"] to more than 900. :-) Not only did the DG fail
to display any data, but it actually KILLED THE DG! I could no longer set the
dgData to empty, nor could I edit the contents in the property inspector and
delete the text. I had to delete the DG and create a new
Hi.
Never thought about this. But I made a DG, and put this into a button:
on mouseup
repeat 300
put random() & tab after temp
end repeat
set the dgText of grp 1 to temp
end mouseup
No problem. With a horizontal scrollbar, I can zoom to each side of the DG.
But If I try to
Hi all.
I'm importing a csv file with a LOT of columns, and I am running into an issue
with setting the dgProp ["columns"] of the datagrid. It's choking on the number
of columns it seems. What is the max?
Bob S
___
use-livecode mailing list
31 matches
Mail list logo
