Resource Hacker seems able to open a 64 bit exe and insert resources and modify the manifest
It’s also a resource compiler extractor etc
I am not complaining about Release 3 not displaying the Windows icons. I am complaining that R4 fails to correct the situation. If you are telling me it is a very difficult thing to do, I will accept that explanation. But to me, Xojo is directing their attention towards less important goals while leaving a serious problem unattended.
Just my two cents.
I will add that adding 64 bit capability is enormous for me, and in this holiday season I should by counting my blessings and not complaining. So I will stop.
64 bit in its entirety is BETA
That includes manifests, resources, and all the other bits required
Since R4 isn’t shipping any talk of it is better placed on the alpha / beta lists
Good point. My apologies.
However, let me respectfully point out that I found out that R4 would not fix the icon problem in this conversation:
[quote=233920:@Norman Palardy]
Since R4 isn’t shipping any talk of it is better placed on the alpha / beta lists[/quote]
It’s certainly something I need to consider, though simply sticking with 32 bit for now and telling my users not to use large amounts of data may be the simpler way to go.
Thanks!
[quote=233918:@Norman Palardy]Resource Hacker seems able to open a 64 bit exe and insert resources and modify the manifest
It’s also a resource compiler extractor etc[/quote]
Tried it. Unsuccessful 
I do believe it is possible to change the taskbar icon dynamically using the code discussed here :
[code]//Change both icons to the same icon handle.
SendMessage(hwnd, WM_SETICON, ICON_SMALL, hIcon);
SendMessage(hwnd, WM_SETICON, ICON_BIG, hIcon);
//This will ensure that the application icon gets changed too.
SendMessage(GetWindow(hwnd, GW_OWNER), WM_SETICON, ICON_SMALL, hIcon);
SendMessage(GetWindow(hwnd, GW_OWNER), WM_SETICON, ICON_BIG, hIcon);[/code]
That does not look out of reach of a declare. I I remember right, this kind of call is used in WFS.
I am in a hotel room with a MacBook and until I am back home I will not be able to experiment.
The idea of using a small 32 bit helper to show the icon is interesting. You will need to manage the opening and closing of that app. Also, you need to suppress the 64 bit icon. See https://forum.xojo.com/13817-creating-an-application-with-no-taskbar-icon/0
[quote=233972:@Michel Bujardet]Tried it. Unsuccessful 
[/quote]
I’d just done a quick test
64 bit apps should be much more malleable than the 32 bit ones simply because they are proper PE32+ windows apps
32 bit are - different - lets just say that 
It looks like adding a standard image resource of any kind will corrupt the dll import table in the EXE (or whatever Xojo calls it). I’ve tried several methods to insert an image resource into the PE executable with no luck. In any case, expanding on Michel’s suggestion (Thanks Michel!), just add the following to a global module:
Sub SetApplicationIcon(Extends w as Window, IconFile as FolderItem)
Const WM_SETICON = &h80
Const ICON_BIG = 1
Const ICON_SMALL = 0
Const GW_OWNER = 4
Soft Declare Function LoadImage Lib "User32" Alias "LoadImageW" (hinst As Int32, lpszName As WString, _
uType As Int32, cxDesired As Int32, cyDesired As Int32, fuLoad As Int32) As Int32
Soft Declare Sub SendMessage Lib "User32" alias "SendMessageW" (hwnd As Integer, msg As Integer, wParam As Integer, lParam As Integer)
Soft Declare Function GetWindow Lib "User32" (HWND As Int32, uCmd As UInt32) As Int32
//=====================================
// Get handle to the Icon Image on Disk
//=====================================
Dim Flags As Integer = Bitwise.BitOr( &h40, &h10 ) //Default size and load from file.
Dim hIcon As Integer = LoadImage(0,IconFile.NativePath,1,0,0,Flags)
//===============================
// Reset the Icon For This Window
//===============================
SendMessage(w.Handle, WM_SETICON, ICON_BIG, hIcon)
SendMessage(w.handle, WM_SETICON, ICON_SMALL, hIcon)
//=================================================
// Ensure the application Icon gets changed as well
//=================================================
Dim ownerHandle As Integer = GetWindow(w.Handle, GW_OWNER)
SendMessage(ownerHandle, WM_SETICON, ICON_BIG, hIcon)
SendMessage(ownerHandle, WM_SETICON, ICON_SMALL, hIcon)
End Sub
Then call it like this in a window open event:
Dim f as FolderItem = GetFolderItem(SpecialFolder.Desktop.NativePath+"mynewicon.ico")
self.SetApplicationIcon(f)I marked it answered because my question was answered in that it is a known issue without a solution at present. The fix for the problem will have to come from Xojo. We won’t be able to build 64-bit Windows apps that are marketable until then. If someone comes up with a workaround before then I’ll change the mark to that answer.
Congratulations, Jim. It works splendidly. Now we have even more than a workaround. We have a way to assign a different icon to a window at any time 
You should mark Jim Cramer’s post for SetApplicationIcon as answer. There is a terrific workaround.
41781 - Windows TrayItem does nothing
OS: Windows 8
Xojo: Xojo 2015r3.1
Steps: I tried to apply the code at Page Not Found — Xojo documentation but it simply does nothing.
The operation appears successful (True), but no new Tray icon appears, nor is the current icon modified.
I noticed a similar issue has been reported for Linux Case 12661
Hi Carl, we have a workaround until the folks at Xojo can resolve the issue.
I haven’t had a chance to try it yet. Does the application file icon display when the app isn’t running?
How do you want the icon to display without executing the code ?
The user does not have to see the actual executable. What you do is use the installer to set the icon for the Start menu shortcuts.
Carl, Advanced installer can do this and several others.
I tried the workaround offered here but I’m not really satisfied with it because it requires an icon file to be called from an external file folder and Advanced Installer requires a license fee for professional use. I removed the answered tag so as not to cause any further confusion given that there does not appear to be an acceptable workaround that satisfies my objectives. I’ll just have to wait until this gets fixed in the IDE before I continue with 64-bit Windows apps.
I don’t like buoys in orange… Rather drown…
Carl, I personally wait with compiling production stuff in 64-bits because it’s clearly stated that it’s in Beta.
Like the new framework. I play with it but because there are known issues, I don’t use it for production. (or carefully use things that (for me) give benefits over the old framework like Xojo.Net.HttpSocket).
Maybe stick with 32-bits until it’s out of Beta? Or maybe we can help fixing the 32-bits issues you ran into that made it necessary to deploy 64-bit builds?