Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Options
Go to last post Go to first unread
KomodoLabs  
#1 Posted : Friday, January 13, 2017 6:55:21 PM(UTC)
KomodoLabs

Rank: Advanced Member

Groups: Registered
Joined: 1/18/2011(UTC)
Posts: 29
Location: Ohio, USA

Thanks: 1 times
Was thanked: 2 time(s) in 2 post(s)
I'd also like to ask if a .Tag property could be added to each icon? It would help us out a lot and we'd be happy to donate some money to the image list for these additional features as it helps us in our commercial software.

Thank you for such great components!
Igor/10Tec  
#2 Posted : Monday, January 16, 2017 9:08:22 AM(UTC)
Igor/10Tec

Rank: Administration

Groups: Administrators, Forum Moderator
Joined: 1/17/2011(UTC)
Posts: 742

Thanks: 10 times
Was thanked: 98 time(s) in 98 post(s)
The main problem of this possible new feature is the icon tag data type and icon tag persistence. I think you expect icon tags as Variants, right? If we need to store these extra data with the control, we need a universal way to serialize/deserialize Variant values so they can be stored in the form data (the .frx file).

At the moment, I see no way to do that - unless we limit our tag icons to strings or another basic type.

And do you need to edit those icon tags in the interface? Another problem for Variant values...

Can you tell us, why do you need these new tag data and how do you want to use them? Wouldn't it be better to have a separate collection of these tag values in your code?
KomodoLabs  
#3 Posted : Tuesday, January 17, 2017 10:38:22 PM(UTC)
KomodoLabs

Rank: Advanced Member

Groups: Registered
Joined: 1/18/2011(UTC)
Posts: 29
Location: Ohio, USA

Thanks: 1 times
Was thanked: 2 time(s) in 2 post(s)
I'd be happy with a string-only comment or note property instead of a true Tag. Would that be possible?

My reason is a little complicated, but I'll try to explain. While in development, we're always needing to edit some icons, so we load all the icons and save them as a .il file. Instead of embedding them in the EXE as a resource, we simply distribute the .il file and load all the icons from it. This way we can edit any icons during development and new versions are automatically loaded. This has been working great and it seems really fast, but we'd like to find a way to only load the icons that have changed. The only way I can think of doing this easily is if each icon in the image list had a file modified date associated with it. I was thinking a .Tag or string comment property would allow us to only load the changed icons. Of course there's file access involved when checking the modified, but I thought it would take less time than re-loading and serializing all the icons. It would also prevent a new .il from being written each time the project starts to run, further saving a little more time. I thought since you'd be digging into the project anyway that maybe it could be added. If not, that's ok. We can continue using the code below. It's even possible that checking modified date for each file is slower than loading, serializing and saving the .il each time we run the app from the IDE.

Here's some sample code below to explain things better. What do you think? Maybe there's an even better way to do this.

Code:
If bInIDE Then

    'Social icons
    vbaIL16.AddFromFile App.Path & "\Icons\Social Icons\Share16.ico", IMAGE_ICON, "Share16", False
    vbaIL16.AddFromFile App.Path & "\Icons\Social Icons\Facebook16.ico", IMAGE_ICON, "Facebook16", False
    vbaIL16.AddFromFile App.Path & "\Icons\Social Icons\Twitter16.ico", IMAGE_ICON, "Twitter16", False

    '...Imagine there are 200 or 300 more lines like the above,
    'or a loop that loads all the files from an entire folder.
    'There are more image lists for 32x32 and other icon sizes as well.

    'Save our image list so our EXE can load it later
    Kill App.Path & "\IL16.il"
    vbaIL16.SaveToFile App.Path & "\IL16.il"

Else

    'Load the 16x16 image list
    vbaIL16.LoadFromFile App.Path & "\IL16.il"

End If

Edited by moderator Wednesday, January 18, 2017 8:56:46 AM(UTC)  | Reason: Igor/10Tec: formatted source code`

Igor/10Tec  
#4 Posted : Wednesday, January 18, 2017 9:01:36 AM(UTC)
Igor/10Tec

Rank: Administration

Groups: Administrators, Forum Moderator
Joined: 1/17/2011(UTC)
Posts: 742

Thanks: 10 times
Was thanked: 98 time(s) in 98 post(s)
The general logic of the development cycle under the IDE is clear. However, I still can't understand how you would load only the updated icons. I think you need to load all icons required to display them in various parts of the interface.

Another question. Let's suppose we've implemented a Tag property for each icon. Do you want the ImageList control to process it somehow? It seems, this is a very specific task that should not be implemented in the ImageList control not to bloat it.

Can you explain your thoughts with some accompanying pseudo-code demonstrating possible usage of the new property?
KomodoLabs  
#5 Posted : Saturday, January 21, 2017 6:04:20 PM(UTC)
KomodoLabs

Rank: Advanced Member

Groups: Registered
Joined: 1/18/2011(UTC)
Posts: 29
Location: Ohio, USA

Thanks: 1 times
Was thanked: 2 time(s) in 2 post(s)
Hi. According to the code, notice that when running as an EXE (not IDE), it loads all the icons from a single file instead of 200 files and saving a new .il. We're not dealing with changing icons most of the time, so we could probably just add a manual Boolean switch for when we are. I was just thinking of a more efficient way since we're on the topic. It's a minor request though.

I thought we'd do something like this for each icon when ran in the IDE. If the .Tag (or comment) for any icon doesn't equal DateFileTime() for the same icon, then it would definitely need to load all the icons like it currently does. But when all the date/times in the .Tag match DateFileTime() for all icons (90% of the time), then it would just load the .il just like when running in the EXE.

But I think you're right. After thinking on it more, it's probably not something that would save much time at app startup in the IDE and could even make things slower. Again, it's already really fast. So I think we can disregard this request. Sorry for the trouble! PNG support is a lot more useful.
Users browsing this topic
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.