I am writing GUI code using PyQt4, as a cross platform library.
On both Windows and x86 Linux everything works fine, but when running on ARM, I'm getting strange behavior. The one I'm trying to tackle now is the fact that dialogs on this platform appear without a caption, which is a little irritating. This is true for both custom and standard dialogs.
Does any one have experience with how to resolve this?
After I noticed that this effect also occurs in non PyQt windows, I looked and eventually traced the problem to the window manager (in this case fvwm)
The solution was to add the following line to the configuration:
Style * DecorateTransient
Related
I have written an application in WPF/VB.net and have been testing it on a few different computers.
I have never experienced this issue on my development machine but one of my test machines has a strange issue where combo box lists and context menus are invisible.
The objects are there and you can select items from them but they are not being drawn.
I am scratching my head with this and have been searching for evidence of similar issues online but not really found anything.
I would like to completely rule out that this is a programming issue before going down the route of pointing the blame at any particular hardware my company is using.
I am using one click deployment and have transparency enabled on my windows.
This is an intermittent problem and restarting the PC will fix the issue. Restarting the application does not make the issue go away.
Thanks
Check that the machine you have problems with has the correct .net framework loaded. If you are using any other products such as Silverlight then check versions.
This issue was fixed by forcing software rendering on windows XP within the App.
This was done by adding the following line to application start up.
RenderOptions.ProcessRenderMode = System.Windows.Interop.RenderMode.SoftwareOnly
First, let me start off by stating that I will be more than happy to post whatever code or other information I need to in order to help resolve this issue. Unfortunately, at this time, I am just not sure what I need to post.
I have a WPF application that uses the Microsoft Ribbon library. I know the ribbon control has been rolled into the 4.5 framework but since I am still deploying to some XP machines, I am forced to use the 4.0 framework. I mention this only in case there is some obscure issue with the old library.
In the application, I have a RelayCommand that is bound to one of the ribbon buttons that does not enable itself correctly (or at all for that matter). The code that is in place to determine if the command can execute is the exact same as the code for a few other buttons. These other buttons behave correctly. Even worse, the behavior is correct on my machine but not on any of the other machines that I have tried it on. It doesn't appear to be isolated to XP or Windows 7. Even worse, I have placed a regular button in the interface that calls the CanExecute method for the command and it reports a value of True even when the button is disabled.
I am at a complete loss of where to start looking. Perhaps someone can steer me in a direction of where to begin.
Thanks in advance to anyone who is able to assist me in my desperate state.
* EDIT *
On a whim, I installed .NET 4.5 on the machine that was not functioning correctly as this was a glaring difference between the development (my) machine and the other machines. To my surprise, this corrected the issue. That said, are there updates to the .NET 4.0 framework that are applied by installing version 4.5? As I mentioned above, I am targeting some XP machines so I cannot install 4.5. Perhaps there are some other updates that can be installed without installing 4.5?
How can I use it on WinRT (Windows 8) - I can't compile it. Can I use it also with "normal" Windows (WPF)?
There isn't currently an mvvmcross port specifically for wpf - a couple of people have suggested building one, but the majority of users have so far requested more work on mobile platforms instead. There is a current console (win32) port and extending that towards WPF should be quite straight-forward.
Future development is now based around the Portable Library branch - see some info on http://slodge.blogspot.co.uk/2012/09/mvvmcross-vnext-portable-class.html and the code on https://github.com/slodge/MvvmCross/tree/vnext
For WinRT, the TwitterSearch example within the vNext branch is a good place to start - it should compile and work across all of MonoTouch, MonoDroid, WP7, WinRT and Console:
If you find you can't compile then please log specific compiler error messages either here or to github issues.
MvvmCrossLibs\MvvmCrossLibs.sln consists of many projects, requiring different runtimes to be installed to open properly (Mono Touch, Mono Droid, WP7). If you only need the library in WinRT, your best bet is to open Cirrious\Cirrious.MvvmCross\Cirrious.MvvmCross.WinRT.csproj directly and add the missing Newtonsoft.JSON package with NuGet (you'll need to save the automatically created .sln file before that). It should compile just fine after that, at keast it did for me. Now just reference the assembly in your Windows Store app project and start using it.
I don't have any previous experience with MVVMCross, but it doesn't look like it currently supports despktop WPF apps. I don't know how difficult it would be to create/compile such a version, though.
I've been tasked with porting an existing Windows GUI app to Linux. Ideally, I'd like to do this so the same code base can be used to build either the Windows version or the Linux version. I'll be doing my work on Ubuntu 9.04. After searching around, it's unclear to me what tools are best suited to help me with this.
A list of loose requirements would be:
The code is in C, not C++, and should compile to build both Windows and Linux versions. Since it's existing code, and fairly large, converting to a managed language like .NET is out of the question for now.
I would prefer if I can use the same dialogs in both systems. In Windows, putting up a dialog is pretty simple. You build the dialog in the Resource Editor in Visual Studio, then call DialogBox() API, and handle the event messages. I would really like to find something that can do the equivalent on the Linux side.
It would also be nice to have a good IDE similar to Visual Studio.
Any helps or hints would be appreciated.
Thanks,
Winelib should let you compile Win32 code under Linux with only a few modifications.
Since your code base is in C, I'd suggest using GTK+. It's a cross platform GUI toolkit. For instance, Pidgin instant messenger GUI is created with GTK+. Glade user interface designer can be used to graphically design UIs.
If you're on a tight budget, and don't mind taking time to work around a fair number of limitations, Winlib is an option. If you're shorter on time, and have a larger budget, you might want to look into Mainsoft instead. It's not exactly perfect, but I believe it supports a considerably larger part of the Win32 API (at a correspondingly higher price).
I created a WPF project in VS2008 and compiled it with Any CPU, x64 and x86. Any CPU and x64 works, but compiling to x86 the application is hanging when running through VS2008 and crashing when running without debugging. Debugging it with WinDbg I can see a StackOverflowException and sometimes a MissingMethodException relating to WPF methods.
Common sense is telling something here that the CLR is not loading the correct assemblies or something when running 32bit WPF apps. I tried reinstalling .NET Framework 3.5 SP1, but it does not fix the problem. I don't know how to go about checking if the correct assemblies are loaded or used.
Any ideas?
UPDATE: Not a real solution but the best I could do quickly was to reinstall Windows 7
Try to force the right compiler in all projects of your solution :
Properties
Build
Platform target
Try forcing Windows to always use the 32bit CLR and see if it still crashes:
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Ldr64.exe setwow
-Oisin
I think I ran into this issue also. If I remember correctly, I had a problem where a dependency was compiled for x86 and the main app was compiled for x64, or the other way around. i.e. say I had a library and an app with a main function. I think they both need to compiled the same way. i.e. I don't think you can mix and match. This might not have been the exact same issue. I would go through all the projects in the solution make sure they all have the same settings.