ICO of the executable file

[krovit]

Good morning/good evening everyone

I often go crazy over this simple sequence of commands: 

$EXEICON: 'myicon.ico' 
_ICON 
_title title$

What happens is: 
1) I don't know because, but sometimes it "fixes" itself so that the icon is not myicon.ico (with the corresponding absolute path) but an old icon that - once the instruction had worked - now it carries along as if it has the memory of an elephant. In other words... it ignores myicon.ico and the icon of the EXE file is that old one, which QB64 seems to like so much... 
2) At the same time, the icon that appears on the title bar of the window (along with _TITLE) is the correct one.
3) _ICON with or without the file (_ICON 'myico.ico') seems to have no effect.

Question: why does this behavior occur and how can I correct it?

Thank you!

[Delsus]

Hello krovit !

I don't think I have an answer for this, unfortunately.

I have almost the same lines in my program, and I don't have any problem with them, except when I use the RUN command to restart the program, I get an error when trying to execute those commands again - which I fixed with ON ERROR.

Does the title of your window change with time?

Else I would just use a custom string and not a variable for the _TITLE command.

Code: (Select All)

 $EXEICON: 'myicon.ico'  

_ICON  

_TITLE "My program"

[SpriggsySpriggs]

You probably need to purge out some temp files and then try again.

[krovit]

Thank you for your responses: even though they do not solve the problem, they have suggested a clue to me.

In fact, I still encounter the problem. I must say that I have several projects, so the problem occurs frequently for me. 

I usually use the DavsIDE editor, and perhaps it depends on it.
In fact, if I compile the project from the QB64 IDE, the icons are the correct ones.
However, if I compile starting from DavsIDE, they are not.

There is no cache to clear (that could be related to the project icons), not even in DavsIDE.
At this point, if he is listening, Dav should tell me something."

[SpriggsySpriggs]

I wasn't referring specifically to icons. I'm saying you should purge all temp files for QB64/Dav's IDE. I'll bet if you do a recursive search on the files that the IDE uses, you'll find some file referencing this icon.

[Dav]

Hi Krovit.  I don’t know what the problem is, but I suspect it’s a path issue.  Have you tried putting the full path in your code to your icon file? See if that helps. Or see if putting icon in the QB64 IDE directory make it compile correctly,  My IDE has had some path issues in the past.  Probably it’s creating the temp EXE in the wrong place and can’t see the icon file, that’s why I suggest a full path to the icon file to test and see it works that way.

The only files my IDE uses in the .ini settings file and a temporary files created when calling the QB64 compiler to compile the source, so there’s really nothing to clear out of it that could help. I will dig up my IDE and play around and see if I can find the problem. 

- Dav

[DSMan195276]

@Krovit when the issue happens again (the EXE icon does not match the one you were using) please check the file `./internal/temp/icon.ico` and let me know if it is the wrong/old one. That file is what gets compiled into your executable, it should be a copy of the most recent icon is but perhaps there's a bug where it's not getting updated.

[Kernelpanic]

The symbol already matches, one just have to provide the path to it.
Deleting the cache is a good idea!

Code: (Select All)

$ExeIcon:'D:\Lab\QuickBasic64\Uebungen\Icon\adonald.ico'

_Icon

_Title "My program"

[krovit]

@Krovit when the issue happens again (the EXE icon does not match the one you were using) please check the file `./internal/temp/icon.ico` and let me know if it is the wrong/old one. That file is what gets compiled into your executable, it should be a copy of the most recent icon is but perhaps there's a bug where it's not getting updated.

I've been on vacation for a few days.

Thanks, Dav and DSMan195276, when I return I will check your suggestion right away.
In the meantime, I managed to work around it by compiling everything through a BAT file and thus staying out of the DavsIDE environment. When the project is particularly complex, it can be convenient to operate this way.

In any case, I took a look: the icons are where you said, and there is more than one. I need to check, I suppose, which one the compiler uses and, if necessary, remove the ones I don't want to use (which essentially means, in a nutshell, to clear the cache).

Dav... indeed your IDE is very relaxing, and I believe it belongs to the category of software that I call 'the maximum of the minimum.' With all due respect, the QB64 editor is really too heavy to manage (but I understand, it comes from the old QB and nostalgia has its weight). It would be even better if it were possible to update, at least, the syntax and a little more.


Thank you so much, really! To all of you.

[krovit]

@Krovit when the issue happens again (the EXE icon does not match the one you were using) please check the file `./internal/temp/icon.ico` and let me know if it is the wrong/old one. That file is what gets compiled into your executable, it should be a copy of the most recent icon is but perhaps there's a bug where it's not getting updated.

I checked for the presence of the file icon.ico in the /internal/temp/ folder of QB64.

I tried deleting everything and then compiling from within the DavsIDE environment using the F5 key: the icon (whose address is correctly entered) displayed in the executable file window is the right one; however, the icon of the executable file is even "old" and belonged to a project I haven't worked on for many months (and I really don't know where it's pulling it from).

If I compile everything through a batch file that calls the compiler, all the icons are correct, so I think I can say that the problem does not depend on the syntax of the QB64 code.

Frankly, it's a behavior that surprises me! I venture a hypothesis: DavsIDE keeps track of the icon's location and writes it down somewhere. I mean, it doesn't copy the ICO file but only writes the path, so it's not possible to trace the icon used in the working environment by searching for the file.