Convert TIconStrip to Image or Pixmap?
BlitzMax Forums/BlitzMax Beginners Area/Convert TIconStrip to Image or Pixmap?
| ||
| Hi! I have loaded a very large Iconstrip and assigned it to a Listbox via "SetGadgetIconStrip(ListBox, IconStrip)". I need the same images in another section of the app as well. So I really would hate to reload them again and keep them in system ram. 1. Can I directly "access" the images stored for the Listbox and draw them in another canvas as image or pixmap? This way I would not need to hold another copy of the strip inside the system ram. 2. Is there a way to convert the Iconstrip to an image or pixmap. So I at least don't need to reload it again from hdd. I would convert it and it would stay in memory for later usage. Don't know if these are truly beginner questions... ;) Thanks as usual, Grisu |
| ||
| The icon strip already contains a pixmap, but if it's for another gadget you can reuse the icon strip without problems. To get the pixmap: Local pixmap:TPixmap = IconStrip.pixmapOr reuse it like this: SetGadgetIconStrip(AnotherGadget,IconStrip) |
| ||
| Ahh, thanks for these informations. Again to my 1. question: Global ListBox=CreateListBox(...) Local IconStrip:TIconStrip=LoadIconStrip(..) SetGadgetIconStrip(ListBox, IconStrip) IconStrip=Null GCCollect() In this example above I have no IconStrip image stored in memory. But the ListBox itself has the items stored in some handle. Can I directly access this handle? So I can draw/display one icon to another Canvas? See my point? |
| ||
| In this example above I have no IconStrip image stored in memory. Yes you do. GCCollect does not free the iconstrip, as the listbox also has a reference to it. You freeing your reference just means you no longer have a reference to it for your use, not that its reference count is zero.I wish people would stop trying to intentionally work against the garbage collector. |
| ||
| That's because I dislike having no control about when stuff is cleared from memory. |
| ||
| Why would you care? It is not removed from memory until it's safe to do so, anyway. It eliminates 90% of all the errors you get in unmanaged languages (the dreaded rogue pointer error, where a pointer is pointing at what is effectively random data). Besides which, you do have control over it. It is cleared from memory, when you stop using it. If you had done what you're trying to do above, in an unmanaged language, you would have frequently experienced spectacular random crashes, that would probably have taken an inexperienced programmer (here I'm talking about the kind of person who would know what color the sky is from person experience) forever to track down. |
| ||
| I dislike having no control about when stuff is cleared from memory. I believe that you can have control over garbage collection if you prefer with GCSetMode 2 and GCCollect. I personally didn't like having to remember to call the old FlushMem and I happily use the default automatic garbage collection, but it seems possible to do it "by hand" for control over timing. Though, as FlameDuck mentions, you'll still have to eliminate all references to objects for them to be collected (but since GCCollect() returns the number of bytes collected, you can test to see if it's doing anything after you attempt to free an item for collection). |
| ||
| I grew up with "freeing" stuff from hand and I like it. Sure, you can have your own opinion about it. :) |
| ||
| I grew up with "freeing" stuff from hand and I like it. So did I. That's why managed programming languages are such a godsend. I can focus on programming game logic, rather than fussing about with memory and resource managers. |
| ||
| I grew up with "freeing" stuff from hand and I like it. Especially as we're not the ones shooting ourselves in the foot. ;op Sure, you can have your own opinion about it. :) |
   |