visual c# application havey flickering on another machine - multithreading

i have developed an application (game) on visual studio 2012 (WFA) in C#, the application includes multithreading and graphics objects (pictureboxs, bit maps, labels...).
now the app runs great on the source pc (the computer it was developed on). but when i try to run it on my laptop it's run with very heavy flickering which is very weird.
source pc - windows 7 net framework 4.6 .
laptop - windows 10 net framework 4.6
*note - both are very strong machines who can run battlefield 4 with no problem.
what is going on??

You've got a software component issue - something that works correctly in 32 bit winDoze is broken in the 64 bit version. Try building your application as specifically 32 bit and run it on the 64 bit machine. Either it will complain about a missing (32 bit) driver (or other softwar component) or it will work correctly.

Related

Visual Basic 6 App on Windows 10 x64

Long story, so please bear with me.
I have an app that I wrote back in 2001 for an AS400/iSeries ISV. Basically, it takes drawing commands off of the AS400, and creates a windows graphic (bmp) file so that they can then display the graphic in their application. Everything has worked great over the years. Now, they have a new customer that is having problems running the application. The problem is that when my application is called from the ISV's software, windows generates a message stating that the application is a 16 bit application and can not be run. I am sure that the application is a 32 bit application. We have tested this on 3 machines running Windows 10 x64 at the ISV's office and do not get the error. We get the graphic and everything runs as intended.
I am guessing that the problem is that the WOW64 layer is somehow not enabled or not setup. Questions:
I thought that VB6 apps were all 32 bit. Is that correct?
Is it possible to not install the WOW64 layer during a Windows setup?
Is it somehow possible in Windows 10 x64 to not enable 32 bit apps?
If you have any other suggestions, we are glad to hear them.
TIA and for your time.
Wally

VS11 beta on main machine?

I'm currently using VS11 beta in a VM but its far to slow and it has crashed. But I was also installed under windows 8 which i found slow so i'm not sure if the speed problems is related to windows8+running in VM or if the produce is also slower.
Is VS11 beta stable on windows7? Does it crash often? (it crashed multiple times for me under windows8 in a vm). Will i have problems developing .NET 2-3.5? Can i have a duel install with 2010 + 11beta?
What should i know before installing the beta on my main machine?
It appears to be very stable.
Personally, I've been using it on Windows 7 for quite a while now (from pre-beta) and have had zero crashes. I've also used it in Windows 8 and haven't seen any speed issues (both bootable VHD and a VirtualBox VM). Your experience may be different.
You can run VS2010 and VS11 side by side. If you have VS2010 SP1 installed projects can be round-tripped so that after you upgrade the project in VS11 it will still work in VS2010.
Working on .NET 2.0 and above is supported.

can I run Windows Embedded CE 6.0 on a regular PC?

As i just need the hard RT capabilities, can I install and run Windows Embedded CE 6.0 on a regular PC ? (dell or so ?), and UDP out some data ?
You can install Windows CE in a PC, but you would need to create your own image. See this tutorial in MSDN. Also google for CEPC.
Finally visit Mike Hall's blog. I remember reading a related article there, but I can't find it now. Anyhow, this blog is a great resource for Windows Embedded.
(From working with Windows CE 5.0, so there may be some differences, YMMV.)
You should be able to run Windows CE both in an emulator and installed on the device itself as the host operating system.
In the first case all you need is an emulator, which is provided with the development kit and in a more expensive version of Visual Studio. This will run the OS fine, albeit a bit slow depending on the architecture you choose to build the Guest OS for.
In the second case you will actually need to find or write drivers for the hardware that you want to run on and use. This will require the Platform Builder application (I believe it's a plugin to Visual Studio now) and knowledge of the hardware that you are running on. Windows CE itself does support x86 processors, although I don't remember if it supports all x86 processors (instruction sets) or just 486's.
If you want to go down the second route you also may be able to get an Intel Atom or AMD Geode board support package (BSP) which will help you develop the drivers.

What problems do you encounter with VFP apps in a 64 bit environment?

I know that there are issues with the VFP OLEDB provider on 64 bit machines. ... but what issues do you encounter while actually running a VFP application - on a 64 bit machine? Has anyone had any experience in this area?
My first thought was that it would just run as a 32bit app, without making use of the 64 bit power. However, I ran into difficulties with a FoxPro application connecting to a SQL Server database (probably an OLEDB issue as well). Are there other issues as well?
This is somewhat of a specialized scenario, and it may not be related to 64 bitness, but since you asked...
My organization recently hosted a legacy VFP 7 app on a Windows Server 2008 Enterprise 64 bit server for access over Terminal Services. The app runs fine, but there is some kind of bug with the TS Easy Print technology. When you print from the app to a redirected client printer over Easy Print, the top, left, and bottom sides of each page of the document get clipped. The workaround we use is to have the users print to pdfFactory on the server first, then print from pdfFactory to the redirected client printer over Easy Print. Works great.
This is somewhat of a stab in the dark...but I believe there are some drivers with MDAC that aren't available in x64 windows. I think you may be able to install the normal 32-bit MDAC but it will install to the x86 folder.
We've seen zero problems with our VFP9 apps on 64-bit XP, Server 2003, Vista, or Server 2008.
Our print engine is a VB DLL though, so we wouldn't run into any VFP-specific printing issues.

AxAcroPDF - Vista64 Class Not Registered Error

We have a WinForms application written in C# that uses the AxAcroPDFLib.AxAcroPDF component to load and print a PDF file. Has been working without any problems in Windows XP. I have moved my development environment to Vista 64 bit and now the application will not run (on Vista 64) unless I remove the AxAcroPDF component. I get the following error when the application runs:
"System.Runtime.InteropServices.COMException:
Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))."
I have been advised on the Adobe Forums that the reason for the error is that they do not have a 64 bit version of the AxAcroPDF ActiveX control.
Is there some way around this problem? For example can I convert the 32bit ActiveX control to a 64bit control myself?
You can't convert Adobe's ActiveX control to 64bit yourself, but you can force your application to run in 32bit mode by setting the platform target to x86.
For instructions for your version of Visual Studio, see section 1.44 of Issues When Using Microsoft Visual Studio 2005
The .Net framework 1.1 is always targeting 32 bits CPUs while .Net framework 2.0 and above can target 32 bits or 64 bits according to the processorArchitecture property of the program manifest changed by the 'Platform Target' option of the Visual Studio IDE.
With the default option 'Any CPU', the IL code is compiled according to the platform but of course the COM call to the AxAcroPDF 32 bits component fails if the platform is 64 bits.
Just rebuild the EXE to target 32 bits platform only. This works fine with the WOW64 emulator in Vista 64 bits.
Use DLL isolation, works with every 32bit COM+ application. See more at:
http://support.microsoft.com/kb/281335
With this solution you can isolate your 32 bit COM+ application into a separate 32bit process.
64bit applications search installed COM+ objects at: HKLM\Software\Classes, but 32bit applications use HKLM\Software\WOW6432\Classes

Resources