!WinEd Renumber Limitation

I have a window with 1250 icons in it. !WinEd only allows numbers up to 999 in its ‘Renumber icon’ text box. So I can’t renumber the icons individually beyond number 999 which seems an unnecessary limitation.
A work around is to select all icons beyond 999 an renumber as a group – this worked sufficiently well for me to get them into the order I required. (Later numbered icons get displayed in front of earlier numbered icons).
Thought I’d mention it in case someone can think of a better work around of the limitation.

If you open !WinEd’s own templates file you should be able to increase the max text length for the renumber icon text box.

I have a window with 1250 icons in it.

To be honest, that might be your real problem. Long before you get anywhere near 1250 icons, you should probably be thinking about other ways to implement the window as the Wimp doesn’t really do lots of icons that well.

Just, you know, out of interest… what on earth are you doing that requires that many icons?

Edwardx : That is such a cunning solution; Use !WinEd to edit !WinEd’s own templates. I’ve done this and it works – Genius !
Steve : Just experimenting to see how far I can push it – 1250 seems fine on Iyonix, a StrongARM Risc PC, and a Raspberry Pi (version 1).
Rick : Messing around with map tiles – scrolls very smoothly if I increase the time before I fetch in another batch of tiles from hard/usb/sd drive, plus I can have a really big map and scroll around it at a most pleasing pace.

Messing around with map tiles – scrolls very smoothly if I increase the time before I fetch in another batch of tiles from hard/usb/sd drive, plus I can have a really big map and scroll around it at a most pleasing pace.

In which case, that’s fairly trivial to do via direct screen redraw – in fact, it’s probably easier than using icons. It’s also scalable; you’re always going to have a finite number of icons in a static template definition. And it’s likely to perform better.

Please, please, do it properly!

Not quite sure why that’s better – my way’s ridiculously simple as the OS does all the work. The work’s in setting up the window which is now done. Many ways to cook an egg ?

There’s something else about a large number of icons in a window that might be worth mentioning. In the past, I’ve done something similar with text icons that were created on the fly. Depending on the type of database, there could be tens of thousands of them! Scrolling was fast, indeed, but I had to increase the wimp slot to really incredible values in order to avoid the run-out-of-memory problem. Replacing those icons by direct font painting solved this, while scrolling was equally fast. So, apart from having more options, doing direct draw also helps you to keep the wimp slot small!

You could also use something in between “put all the icons into the window and let the WIMP do all the stuff” (which is not ideal concerning memory consumption and speed) and “do the redraw all for yourself” (which is fast, but complicated if you need just the simple stuff an icon can handle).

There is Wimp_PlotIcon which I use in CDVDBurn for the warning/error log window and the pseudo filer. Basically, you use the well-known icon data structures, but you don’t use Wimp_CreateIcon to put all the icons into the window, but wait for the redraw event and then work out which icons to plot. That way, you only need to have one icon data structure in memory and update it just before plotting the icon.

StrongHelp Wimp manual calls these icons “virtual icons”.