• Print

Author Topic: _ICON to be implemented in QB64-GL soon [Windows only]  (Read 77 times)

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 4664
  • QB Forever
    • Email
_ICON to be implemented in QB64-GL soon [Windows only]
« on: May 11, 2013, 07:11:48 AM »
Just a quick post to let you know that _ICON will be reimplemented in QB64-GL.
Whilst maintaining full compatibility with QB64-SDL I've added an optional 2nd argument.
_ICON main_icon_handle,  window_icon_handle
Typically you'd supply a low-res (16x16/32x32) image for the window and a larger (64x64/???) icon as the main icon. If you supply only one image, it's used for both.

Also, alpha will now be used and QB64 can detect the size of the Windows icons so results will look far more professional.
Something old... Something new... Something borrowed... Something blue...

Clippy

  • Hero Member
  • *****
  • Posts: 16426
  • I LOVE π = 4 * ATN(1)    Use the QB64 WIKI >>>
    • Pete's Qbasic Site
    • Email
Re: _ICON to be implemented in QB64-GL soon [Windows only]
« Reply #1 on: May 11, 2013, 08:43:04 AM »
Are ICO files supported?  Will they work with _LOADIMAGE too?

If the icon is used by Windows, then it would be embedded into the EXE file would it not? If so, why not skip the _LOADIMAGE handle and put the file name straight into the program using _ICON "filename" directly. Then the file would not be required to be included with the compiled program. It could be an alternate syntax.

Also it could be included as an option in the IDE for users to use their own icons repeatedly.

I never did understand why _LOADIMAGE was required in the first place. With embedded icons, _ICON could do all of the work as the file can be read internally.
« Last Edit: May 11, 2013, 12:46:25 PM by Clippy »
QB64 WIKI: Main Page
Download Q-Basics Code Demo: Q-Basics.zip
Download QB64 BAT, IconAdder and VBS shortcuts: QB64BAT.zip
Download QB64 DLL files in a ZIP: Program64.zip

OlDosLover

  • Hero Member
  • *****
  • Posts: 3859
  • OlDosLover
    • Email
Re: _ICON to be implemented in QB64-GL soon [Windows only]
« Reply #2 on: May 11, 2013, 08:59:34 AM »
Hi all,
    Great addition , thanks.
OlDosLover.

wiggins

  • Jr. Member
  • **
  • Posts: 50
Re: _ICON to be implemented in QB64-GL soon [Windows only]
« Reply #3 on: May 11, 2013, 02:05:36 PM »
>  _ICON to be implemented in QB64-GL soon

:-) and thank you

DSMan195276

  • Hero Member
  • *****
  • Posts: 1974
  • Yes
    • Email
Re: _ICON to be implemented in QB64-GL soon [Windows only]
« Reply #4 on: May 11, 2013, 02:40:06 PM »
I largely agree with Clippy on this one, to an extent. I can't say that I think _ICON "filename" is a great idea because of the memory leaking issues it could create (The same thing happens with "SCREEN _newimage()", using it repeatedly makes a memory leak). Having to store the handle to the image is much better practice then just discarding the handle. Chances are you'll need the handle at some point anyway, and not having it makes you have no way of freeing the image. Not having access to the handle like 'SCREEN _newimage()' doesn't mean the image will be freed on it's own (Perhaps it should be, but that's up for debate).

That said, I do however think that being able to embed the icon and load it up directly from the executable would be handy. Since it's going to be done at compile time, a meta-command such as $ICON could be used to signify a file to compile in. (Perhaps, even a more general '$IMAGE' meta-command to compile images in? Worth thinking about). Then, as long as you could get a handle to the attached images (like other images) you could easily switch between having something compiled in or not without having to modify the program much, which really should be the intention (Whether or not something is compiled in should hopefully not matter to any of the image commands besides _LOADIMAGE). The idea does have some issues that need to be worked out, but I think that if the image was just copied into memory when it's loaded up from the executable then there won't be any issues (Since at that point, it's just a regular image).

Matt
"Cast your cares on the Lord and he will sustain you; he will never let the righteous be shaken" -- Psalm 55:22
QB64 Linux Installer

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 4664
  • QB Forever
    • Email
Re: _ICON to be implemented in QB64-GL soon [Windows only]
« Reply #5 on: May 11, 2013, 07:45:00 PM »
For now I'm just implementing QB64-SDL functionality.

Ideally, we'd also have a meta-command that embeds icons into your executable.

As for opening .ico files, their format is very straightforward but I've got other priorities atm, when I get around to it (or heaven forbid someone else does) you can bet it'll be added to _LOADIMAGE asap and embedding icons will follow. What we want to avoid is being dependent on a particular type of icon format, after all they are just multiple images. _LOADIMAGE will have to be extended to be able to read multiple images from the same file at some point, but that will also lead for requests to get cursors, hotspots, animated gif timing, etc etc so there's potentially a lot of work there.

Something old... Something new... Something borrowed... Something blue...

OlDosLover

  • Hero Member
  • *****
  • Posts: 3859
  • OlDosLover
    • Email
Re: _ICON to be implemented in QB64-GL soon [Windows only]
« Reply #6 on: May 11, 2013, 08:36:55 PM »
Hi all,
   
Quote
(Perhaps, even a more general '$IMAGE' meta-command to compile images in? Worth thinking about).
    This is a very good idea. It would take the ambiguity out of knowing if the images are available regardless from where the exe is launched. I seem to remember that somewhere it was said that porting to Android would have this built in?
OlDosLover.

Clippy

  • Hero Member
  • *****
  • Posts: 16426
  • I LOVE π = 4 * ATN(1)    Use the QB64 WIKI >>>
    • Pete's Qbasic Site
    • Email
Re: _ICON to be implemented in QB64-GL soon [Windows only]
« Reply #7 on: May 11, 2013, 09:35:29 PM »
Icon structures are not hard to do. I have already done them with multiple images. All that has to be done is convert it to C. I've used them with QB64 without using _LOADIMAGE. I even converted them to bitmaps so that _ICON could use them.

http://qb64.net/wiki/index.php?title=Icons_and_Cursors

The biggest problem would be specifying the one you want to use. That's why I think the IDE could be useful to set it up. Perhaps a preview? If no icon number is given, it would default to the first one.

If the image is embedded then any "leaks" could be avoided as the program would have direct access much like the QB64 icon already hidden in the EXE. Memory leaks would not be created by the file itself so put the blame somewhere else.  ;)

I'd like to see the ability to add other resources to programs too. Michael could help.

« Last Edit: May 11, 2013, 09:42:15 PM by Clippy »
QB64 WIKI: Main Page
Download Q-Basics Code Demo: Q-Basics.zip
Download QB64 BAT, IconAdder and VBS shortcuts: QB64BAT.zip
Download QB64 DLL files in a ZIP: Program64.zip

DSMan195276

  • Hero Member
  • *****
  • Posts: 1974
  • Yes
    • Email
Re: _ICON to be implemented in QB64-GL soon [Windows only]
« Reply #8 on: May 11, 2013, 10:01:50 PM »
I think it'd be better to just have some way of specifying what image to get from the file in the code. But either way, figuring out a way to specify what image to load in code shouldn't be that complex to do, definitely not the biggest hurtle here. GIF's could also use the same support for accessing multiple images in them as well.

Converting that to C shouldn't be very hard (But, if Galleon can't do it, it would be a while before I'd be able to take a stab at this.). Seeing as BMP code was recently put into QB64, we could probably base the code off of that (or even just extend that code) to make it easier to get the stuff that has to go on with QB64 internally correct. The only thing that worries me a bit is the compression (BMP's have the same issue, I don't know if QB64 currently supports compressed BMP's). Are you sure that the compressed byte will always be set to zero? If that's the case then that will definitely simplify things, if not then adding support for the compression schemes would be needed.

Assuming the ICON file is embedded, then depending on what support we give to this idea memory leaks will still be a present issue. I know what you mean by memory leaks can't come from storing something in a file, but to display the image you unavoidably have to read it into memory. I'd much rather add support for being able to embed any type of image you want instead of just allowing embedding icons and then probably added another separate command for everything else later on (Though, if icon's have to be embedded in a bit different manner, then that's a different story).

Since _ICON takes an image handle and currently uses an image to display it, that image does need to be freed at some point. _ICON "filename" doesn't allow you to free it, creating a memory leak. What it should do in this case to allow you to avoid that memory leak is debatable, but currently there would be no way around that issue. It's really not that big of a deal though, as long as you just make sure you get a copy of the handle via _LOADIMAGE() before using _ICON then you can always free it when needed.

Matt
"Cast your cares on the Lord and he will sustain you; he will never let the righteous be shaken" -- Psalm 55:22
QB64 Linux Installer

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 4664
  • QB Forever
    • Email
Re: _ICON to be implemented in QB64-GL soon [Windows only]
« Reply #9 on: May 12, 2013, 03:42:45 AM »
Here's a screenshot of the new _ICON command being used to full effect (alpha and separate icon for window icon vs program icon). I magnified the view so you can see the alpha effect a little more clearly.

What I intended to do was eventually provide a $ICON meta-command like...
$ICON: "qbicon32.png", "qbicon16.png"
At compile time it would use given images (including selecting from multiple if available, eg. in a .ico) and embed them in your executable as the executable file's icon and the default program icons at run-time. Most importantly, it would negate the need to have image decoders in your application simply to use an icon because the QB64 compiler would load, analyze and embed the images given appropriately for the given platform.

I've taken the liberty of reworking the current QB64 icon a tad whilst still keeping the layout of the original.
Something old... Something new... Something borrowed... Something blue...

  • Print