I am creating an app for a client. It is written in 32 bit MFC using Visual Studio 2010 and run on 64 bit Windows 7 (compatibility with other versions of windows not required, it's for a very closed system on limited machines) The program will be started automatically in minimized mode when the machine boots.
The program collects data from a bunch of serial ports, and if restored, shows specifics and allows the user to change or fix things, but when minimized should just show a single "red LED" icon to show something is amiss, or a "green LED" icon to show everything is OK, no user intervention is required.
On my development machine (also Win 7-64), running the program from within Visual Studio or directly from Windows Explorer, when I change the icon using CWnd::SetIcon it changes in the window and in the taskbar, just as I want it to. If I make a shortcut to the program and start it with the shortcut, the default icon is displayed in the taskbar and will not change. Fine, it's taking the icon from the shortcut, that is explained.
The odd part is that on the target machine, no matter how I start it, including clicking on in using Windows Explorer in it's folder (like I did on my development machine), or using the Windows Registry "Run", it always uses the default icon, and never changes in the taskbar. I expected that when I used a shortcut on the desktop or in the Startup folder, since that was the behavior on my development machine.
So why would it work on one machine, when run directly from the exe, and not on another of the same windows version?
More to the point, how can I make it work on the target system? I also need to make sure that solution will work when autostarted on power-up/login.
Related
Our users are experiencing crashes when Windows 10 Creators Update (1703) is automatically installed through Windows Updates. The Windows application of ours is a multilevel, C++ WinForms application. The application can start, but if we click on certain menus, it crashes. Appears to be a graphics issue or something to do with fonts, perhaps. Why?
When the Windows 10 1703 update was applied, the installer replaced the Windows/Fonts directory and did not include shortcuts to fonts included elsewhere in Windows.
In our case, our application was needing Lucida Sans Typewriter font, which had been registered with Windows, but located in a bundled JRE for IBM Client Access off Program Files (Our application uses some IBM Client Access components).
Shortcuts of the Lucida fonts were in the Windows/Fonts directory before the update, but absent after the update (which caused our application to crash).
The Fix: We had to copy/paste all the Lucida fonts (there are 8 of them) required from the embedded JRE/lib/fonts directory into the Windows/Fonts directory to resolve the issue. We found if we did this before the 1703 update or after, our application continued to work.
The Lesson: We are going to ensure our applications use fonts that we control 100%, by copying them into Windows/Fonts during install.
I am writing a cross-platform application in C++ using Visual Studio.
My project type is the most basic one "Win32 console application".
I admit it, I haven't mastered all bits of windows software development, but there seems to be a clear pattern:
When you run an application from a CMD session, by default, Windows connects the app's default stdin/stdout/stderr with this CMD session.
(I.e. when you type 'dir' in a cmd session, it doesn't fire up a new cmd window.)
This is, however, not the case when running an application from VS. That is, when I press F5, it fires up a new console window, runs my console app inside this window and connects stdin/stdout/stderr with this console window.
What I want is instead to connect stdin/stdout/stderr with a sub-window inside the Visual Studio itself. (Akin to an "Immediate" window.)
Then I won't have to switch back and forth between VS and CMD.
Clearly, there should be some mechanisms to achieve that, since from an ordinary command prompt I could do something like:
a.exe 1>stdout.txt 2>stderr.txt <stdin.txt
I'd like Visual Studio to do something like that when running my application, but instead of files, connect the streams to a sub-window in VS.
The principal thing here is that this should be done without any modifications to the application code itself, because it must be completely independent of the development environment and/or platform.
(That's why I didn't use one of the many solutions found on stackoverflow -- they all are based on some adaptation of the application code.)
I am developing my Qt (c++) application on MacBook. However, the application might run in both Windows and Mac Systems.
Is there is a way to set platform independent application icon ?!
Setting application icons is already independent, Windows and OS X require different icon formats: http://doc.qt.io/qt-5/appicon.html
the application might run in both Windows and Mac Systems
Right, but not the same executable (binary), you'll compile two versions, one for Windows and one for Mac. Executable icon could be displayed by the OS (when aplication icon is shown on desktop, task bar...) before the application is actually started. So this icon cannot be set programmatically, it must be set at compilation time. And, you must refer to this post to know how to set the application icon for binaries on each different platform.
I am creating a shell-replacement for developers, which creates a new windows user, titled "developer" and only when you log into this user, should the shell be launched.
The replacement start menu is replaced with a shell based terminal with great features, the taskbar is replaces with a tree based view for windows, and the process monitor is replaced with a view where you can attach process monitors, debuggers, profiles, and memory leak detectors, etc.
I would like my application replace the regular windows shell. I have however came across a registry key that, on windows 7, works just fine. but on windows XP if I use the regular windows XP file manager the windows XP task bar from explorer.exe launches, even though I changed said registry entry!
Does anybody have any idea what it is I need to do to fully replace the windows shell AND taskbar using windows XP while still retaining use of the windows based file manager?: )
Edit:
Using C++, developing using NetBeans using Qt for my gui library. however, as I do not think this should effect the answer, I figured I would include it either way.
I believe Windows XP does not support per-user shell replacement (not sure, it's been a while since I played with the desktop stuff), but you should be able to set the 'Shell' entry under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon and prevent Explorer from registering itself as the shell when it first runs. This will affect all the users in the machine, of course.
Well, I am facing a strange problem. I have developed a sample MFC ribbon application on my machine - Windows 7 , with Visual Studio 2008. When I copy paste the .exe onto my laptop and run the app , I don't see the ribbon menu (in fact the app has not menu now) .
I have tried looking up the .dll that load in each case(on my work machine and laptop) using process monitor but I am unable to locate what I might be missing. Any help will be greatly appreciated.
Edit 1 -
Ok, So thanks for your responses. Some progress has been made with this issue
I changed my IDE to VS 2010. The ribbon was coded manually and I figured out if I could add it as a resource maybe the problem would be solved. VS 2008 did not have the option of adding a ribbon as a resource.
I installed the VS 2010 Service Pack Redistributable X86/X64 depending on whether the machine is 32 or 64 bit.
I built a new "ribbontest.exe" app from VS 2010 and deployed it on other machines on which I would test my actual app. The ribbon for "ribbontest.exe" loads without any problems.
When I deploy my app and run it, first the old menubar loads for a sec or two, then the ribbon flashes and disappears.
A little history of the app I am referring to -
Initially my application had the menubar view. I followed this article http://www.codeguru.com/cpp/cpp/cpp_mfc/tutorials/article.php/c14929/MFC-Feature-Pack-An-Introduction.htm to accommodate a ribbon.
Any suggestions?
Most likely there's a conflict in the settings 'paths'. In your InitInstance() handler, you've got a statement like this:
// Standard initialization
// If you are not using these features and wish to reduce the size
// of your final executable, you should remove from the following
// the specific initialization routines you do not need
// Change the registry key under which our settings are stored
SetRegistryKey(_T("yourappname"));
If you haven't changed that name yet, do it. If you did, open regedit.exe on your target machine and remove the whole key under HKCU\Software\yourappname and then try again.
MFC stores user customizations of Ribbons/Menus/... under that key. But if you changed your app those settings don't necessarily match anymore and you can end up with stuff not showing correctly or not at all.
Make sure you download and install the Visual C++ Redistributable Runtime on your destination machine: http://www.microsoft.com/en-us/download/details.aspx?id=29
Or, something like it. Make sure you have architecture (x86/x64) correct and make sure it matches with the service pack version you compile with.
Joe is right: you need redistributable.
Joe is right: you cannot run 64-bit program on 32-bit machine.
All of the above would be indicated by the system (missing DLL, configuration incorrect, or 64/32 bit discrepancy)
Joe is right: your application must be built for specific set of minimum Windows version and service pack.
In addition to Joe’s post you must run release build not debug build.
If all of those requirements are met and you still have this problem, try linking MFC statically and see if problem persists.