Some images do not show in SRP edit-table

vince

When populating an SRP edit-table with 5000 or more thumbnail images obtained by searching a database table, certain images (sometimes individual, often one or more ranges of image) do not appear. The specific images that fail to appear differ from one search to the next. I checked the OLE.CellImage property with Get_Property, and the filesystem path to the thumbnail is always correct; nonetheless the SRP table shows a significant number of empty cells throughout.

I use:
Set_Property(@Window:".OLE_THUMBNAILS", "OLE.CellImage[":icol:";":irow:"]", location:@FM:"None")
and:
Send_Message(@Window:".OLE_THUMBNAILS", "QUALIFY_EVENT", "OLE.OnClick", 1)

Is there a way to verify that an image has actually been loaded into a cell?

KevinFournier

Given that the failing images differs in each search, I'm inclined to suggest that you're running into memory issues. How big are the images you are loading? Just because they are drawn small doesn't change the fact that each image is loaded in memory at it's original size. If, for example, each image was 1MB, then loading 5000 of them would take up 5GB of memory. Moreover, just because an image might be a 200K JPG doesn't mean it loads to 200K in memory. All images, be them JPG or PNG, end up as 32 bits per pixel in memory. So, an image that is 1000 x 1000 takes up 4MB, even if it was just 200K on disk. Watch the Task Manager to see what happens to memory as OI runs.

If it turns out that certain images tend to fail more than others, I'd be happy to take a look at those images to see if there's some feature that prevents loading properly. For example, we recently discovered that 64-bit images wouldn't load, a fix that will be forthcoming in the next release.

vince

I think you hit the nail on the head about memory. Each PNG file is 320 x 226 pixels, so by your numbers 282.5 kB in memory. Four images use 1130 kB or about 1.1 MB. In the task manager I observe that, when I scroll one row down (each row has 4 images), the memory used increases by 1.1 MB.

Is it possible to add "Next" and "Back" buttons to an SRP edit table? If so, would the memory problem go away, or are the buttons equivalent to the scroll bar in terms of loading into memory?

Lending support to the memory argument, where the empty cells appear depends on how one scrolls through the table.
Scenario A:
1. Find 5000 images to load in SRP edit-table: ~400 MB used by OI
2. Then drag side-bar down quickly to last row: ~410-700 MB used
3. Then scroll up until first empty cells: ~1660-1700 MB used, roughly 4/5 of the way to the top of the edit-table. From here to the top, groups of images are separated by groups of empty cells.

Scenario B:
1. Find 5000 images to load in SRP edit-table: ~400 MB used by OI
2. Then scroll down until first empty cells: ~1660-1700 MB used, roughly 4/5 of the way to the bottom of the edit-table. From here to the bottom, all cells are empty.

Thanks for the insight, Kevin. I look forward to your comment on a "Next" button, which is the suggestion here. I don't think it will work, but with only a few months experience with OI and SRP tools I could easily be wrong.

FrankTomeo

Speaking from experience on using the the edittable (and other controls) in ways Kevin never dreamed of - I would say it would be completely possible to implement your own 'next' and 'previous' functionality. However, I think what you are looking for is something already built into the edittable that would handle all this for you, and that is just not there. What is there, is the ability to setup the edittable to act like a non-scrolling 'window' into your array of data, with some other controls on the side (buttons, hyperlinks, etc.), that the users use to control paging through the data. Behind the scenes, you load the list into memory and display the images and 'chunk' of data the window is looking at, based on the users' paging actions.

vince

Okay, that may be a way forward.