gadget limitations - eg text gadget

[eck49]

I've just hit a limit of 2^15 pixels for the height of a textgadget.

Two questions:
*1* I'd like to write (potentially) a few tens of thousands of short lines of text to a text gadget - where the user may scroll up and down the text but cannot change it. Given the height limit of a textgadget, is there a reasonable alternative?

*2* Are the limits Purebasic sets on the sizes of gadgets (whether height, width, numbers of rows, whatever) documented anywhere? The online reference manual seems a bit patchy on this, unless I am not looking in the right place!

[infratec]

Use an EditorGadget() in readonly mode.

[eck49]

@infratec
Thanks, I will.

[Tenaja]

Another alternative, although likely Overkill, is the scintilla gadget.

[TI-994A]

Another alternative, although likely Overkill, is the scintilla gadget.

Some working examples:

> EditorGadget() & ScintillaGadget()

[BarryG]

I've just hit a limit of 2^15 pixels for the height of a textgadget.

That's 32768 pixels... your desktop wouldn't even support that resolution to show it. So, what do you mean?

[RASHAD]

You can try ListViewGadget()
But with tens of thousands you may need more than one list

[spikey]

I've just hit a limit of 2^15 pixels for the height of a textgadget.

This limit pops up now and again on Windows. It arises from two sources I think - API functions which date all the way back to the 16-bit versions of Windows and nobody has had a need to replace and/or compressing two signed 16-bit co-ordinate values into one 32-bit value by 'shift-or'ing one value into the high order bits of another.

For example, it constrains also the width of the header control in a ListIconGadget and the internal width of a ScrollAreaGadget. See viewtopic.php?f=13&t=74696

It seems to affect X/Y/W/H based co-ordinate parameters, for the reason that BarryG observed, and API messages where lParam is not a pointer to a structure but that may be a gross generalisation.

[eck49]

Thanks, one and all.
Yes, scintilla is overkill....
@BarryG. The gadget was in a scrollarea, so not trying to have it all visible at the same time. Of course the EditorGadget makes the scrollarea redundant and is way faster, although there are off-topic issues.

@spikey. Hmm. That is helpful information (including the link). But I am exclusively on Linux. Do you think the limit has been inherited from somewhere (say in the pre-Cambrian slime pre-Windows!) or is it something kept to retain cross-platform compatibility?

[spikey]

But I am exclusively on Linux

I really should have spotted that - sorry! I'm clearly having an off day!

Do you think the limit has been inherited from somewhere (say in the pre-Cambrian slime pre-Windows!) or is it something kept to retain cross-platform compatibility?

The true answer is neither because it's a case of parallel development of different systems not forked development of a common ancestor.

The bit about desktop size still applies though. Nobody realistically has a desktop that big so API functions most likely won't allow for this because the memory requirements and function speed will be adversely affected. Everyone is looking to make graphics performance better not worse...

[eck49]

@spikey. No problem, most folk on here are Windows users even if they use other machines as well. And I do have a Windows machine, an old Windows95 one!

Making performance better is good, but for some problems this may not mean faster but widening the range of what can be done. In an ideal world, best to give the user/developer the choice.

[IdeasVacuum]

The best way is to produce an HTML file (no internet required). Easy to create and excellent presentation is easy too. Plus HTML is lightweight, good performance is standard.

[mrv2k]

I use a virtual listicon gadget in a Mame frontend I wrote, which can display 43000 text lines pretty much instantly. Might be worth a search on the forums.

[eck49]

@mrv2k Would you spell out for me what you mean by a 'virtual' gadget? And what is Mame?