After I clicked the code:: block icon, the code::block app icon kept flickering or flashing in the taskbar until the app was opened completely.
Flashing the icon in the task bar, while opening CodeBlocks, is not a problem that compromises the operation of the IDE.
Is due to loading the wxWidgets libraries used by CodeBlocks.
The issue has been fixed in the developing version (Nightly builds).
Related
so I wanted to switch between projects in VSC on my MacBook Air (macOS Monterey) so, like usual, I went for a top bar, selected File, chose Open Folder. But then the Finder window that was prompted stopped responding for my touchpad clicks. It does respond when I try to crawl through folders with my keyboard but at the end I can't choose the folder to open. Any advice?
I'm also experiencing the same issue on my M1 Mac on OS Monterey 20.6 in other applications as well as VS Code. The only solution I found is the workaround posted here: https://discussions.apple.com/thread/253580300
Simply adjust the Finder window size by hovering the mouse over the corner/edge of the window then click & drag. This then makes the Finder window responsive to mouse clicks.
I am developing an Mac OS app, and have preference window presented as model. This works just fine as I want and I don't want to change that behaviour. The problem is: when the window is shown, and I debug on some breakpoints, the preference window is still there, however, Xcode's app is in focused now, but the preference window from the current app still shows on top. This is annoying. I have to drag it to somewhere to see the Xcode window. Is there anything that I can do so that if the app is in debug mode, then that preference window should also be gone away with my app in background and just Xcode is in foreground?
When a window is run as a modal window, its window level is set to NSModalPanelWindowLevel, which is above normal windows. As a hack just for debugging, you could do something like this just before running the window as modal:
dispatch_async(dispatch_get_main_queue(), ^{
NSApp.modalWindow.level = NSNormalWindowLevel;
});
Another approach would be to just run your app on a separate desktop space from Xcode.
I have been using Xcode 4.3.3 for a few days on my retina mac (Lion, of course). At work I always have my Xcode window on a Cinema Display and have never experienced any problems. However, I threw an Xcode window onto the pro's display and tried to resize the debug bar - Xcode hangs. 99-100% CPU and the cursor turns into the rainbow wheel of death. I tried deleting everything in ~/Library/Developer/Xcode/DerivedData because that has cleared up all of my issues with Xcode in the past, but that's a no go. I want to do some iOS development when I am not at work, but this makes it pretty hard to do since I don't have a cinema display or other monitor at home.
Here's the sample from the Activity Monitor:
http://pastebin.com/2Suz1b9v
I figured it out. By default, Apple opens Xcode in a resolution optimized for the Retina Display. You can force XCode (or any other application) to open with a lower resolution by doing the following:
Quit the application if it is currently open.
In the Finder, choose Applications from the Go menu.
In the Applications folder that opens, click the application's icon so it is highlighted.
Choose Get Info from the File menu.
Place a checkmark next to "Open in Low Resolution" to enable Low Resolution mode.
Close the window and double click the Application to reopen it.
And it works!
We have a windows app, written several years ago and maintained over time. We do not have any specific code to handle any Windows 7 UI features. Just plain old Winforms and WPF. We are seeing issues with closing windows using the Taskbar's preview and close button.
On some workstations, when the window is re-opened (calling the same tool via a menu), it is empty (white/blank). On other workstations, the same window is drawn outside the screen.
While there might be some custom code to initialize the window and restore it in the right location, what is troubling us is that none of those issues exist if we close the window using the standard close button on the title bar or using a "close" command.
Does anybody have any idea what is different between the closing of a window using the Taskbar and the standard button?
Regards,
Eric.
I have a normal MFC Application with an embedded icon. If I start the application, the icon is shown inside the windows-7 taskbar.
But when I change the icon inside the resources, rebuild the application and start it, the taskbar doesn't show the current icon, but the icon from the first run.
There is no special code inside the application that does something specific with the windows-7 taskbar.
Is there a way, (in C++) to tell the windows-7 taskbar to show the current icon?
Did you empty/delete the shell icon cache?
I believe that if you rebuild an application, but it's still called by the same name, then explorer doesn't think it should reload the icon, even though the new icon is the only one in the app.
If you were to release the program, no-one else would have this problem since the first version of the app would have the new icon, but for your own purposes you can call SHChangeNotify(); from shell32.dll to refresh your own view of the icon.
did your remove the previous icon from resource....and assign the new icon to the file..too after putting in the resource...might that would work....