Hey all, i have been using VB.net 2008 for a few months and i have a question. I compiled my program and ran it in a VM running windows 7. However, the progress bar looks like it does in XP. It doesn't have that cool look to it like I've seen in many other programs running in windows 7.
I have downloaded the 3.5 .net framework with sp1 and also the sdk for windows 7 (1.4+ gb dvd) but i still see nothing.
Is there a check-box i am missing in VS 2008 to enable these types of features? Maybe some type of code i need to place in the program?
Thanks!
David
I think you're looking for System.Windows.Forms.Application.EnableVisualStyles :)
The Windows API Code Pack can be used to get access to some Win 7 (and Vista) controls etc:
http://code.msdn.microsoft.com/WindowsAPICodePack
You can also use the SetWindowTheme API function to make the standard controls look more 7ish.
Here's a link to a project that uses SetWindowTheme to get Vista style controls, should be similar for Windows 7 (quite possibly the exact same code sometimes):
http://www.codeproject.com/KB/vista/themedvistacontrols.aspx
Related
Since few days I have tried to apply this ActiveX to my Excel 2013.
I made small app for running reports in Excel and I need some way to pick start and end date.
Easiest way to do it was Date And Time Picker Control which is in %windir%\syswow64\mscomct2.ocx.
It worked perfectly at Windows 7 64-bit + Excel 2010 32-bit.
When I moved my project to other PC with Windows 7 64-bit and Office 2013 32-bit it stopped working. Firstly there was class missing, so I registered Microsoft Windows Common Controls 2 6.0 (SP3) in syswow64 using regsvr32.exe command.
It did not help - it was keep saying "cannot insert object".
Tried another versions of Common Controls (currently SP6), but problem is still there - I can`t put any control to my Excel worksheet.
I`m running out of ideas and tutorials, so maybe some of You had ran into this type of problem and have solution?
It's best that you just abandon your search for a Microsoft solution. They haven't updated the common controls for 64-bit. Your best options are to create your own ActiveX Control by wrapping the Date And Time Picker Control from .Net or communicate using COM and expose the features that you want, or use one of the custom VBA solutions that can be found on Ron de Bruin's Calendar/Date Picker page.
I've used this one - Calendar Control for All Office versions - including Office 2010 64 bit
but this one looks better IMO - A Pop-up Calendar for Excel 2007 and up
Even if you can get it running on your machine, if you work at a large company, like myself, you'll never get IT to deploy the fix to everyone.
Edit: was getting confused with MSCOMCTL.OCX issues
I am developing for Windows 8 since before the release of Windows 8.1. My project is targeting Windows 8 devices. As Windows 8.1 is about to hit the market, do I have to change the platform of my project? Can I continue to develop it as it is? How long do I have until I must change?
The short answer is yes, there are quite a few big differences in Windows 8.1 than Windows 8.
One of the biggest ones is the lack of a LayoutAwarePage. Your app will need to accommodate almost any screen sizes and widths, which will mean that you will likely need to do all of your layout using relative spacing instead of absolute spacing (which you should be anyway). There are quite a few other changes, but many of them are tools given to the developer to make things easier or better. You should read them though, as you'll need to make the move eventually
Links thanks to #Xyroid - Migration Windows Store App based on 8.1. does it has backward compatibility with 8?, Resources for Migrating to 8.1 & Upgrading Windows 8 Apps to Windows 8.1 - Channel 9.
The links he has provided are truly top notch. Definitely check out Resources for Migrating to Windows 8 (the second link). It is from Jerry Nixon's blog, and is a great set of resources. Also, the Channel 9 videos from Build 2013 are an amazing set of resources. They will also likely have subtitles in case English is not your preferred language (at least, many Channel 9 Build videos in the past have).
The main changes are also in this blog post http://blogs.windows.com/windows/b/appbuilder/archive/2013/07/24/windows-8-to-windows-8-1-preview-starting-with-the-xaml-templates.aspx
I just ported one of my C# .net programs to run with mono on linux. Functionally it seems to be working, however under linux the program looks very different. It seems that many of the user controls have grown with respect to the main window, this results in a lot of truncation and scroll bars that are not present when built with visual studio. I tried this:
http://www.mono-project.com/FAQ:_Winforms
but that didn't help. Is there a way to make my program appear the same with mono/linux as with .net/windows? I realize that I may have to redesign the form slightly.
Also, since I loaded my .net project into mono I can't see to find the form designer? How can I the form layout of my program linux side?
So the problem here is that if you make WinForms look like Windows on Linux, people complain it doesn't look native on Linux, and if you make it look native on Linux people still complain.
That said there might be bugs causing the UI to show incorrectly - you should try to create small test cases and file bugs (and in the process you'll likely find out what works on both platforms).
There is no form designer on Linux, you need to use Visual Studio for design-time support.
I have this annoying bug in MS Expression Web 4 SP2, weird GUI quirks: you can see in the picture: like parts of the display isn't being painted. I had this before, and solved it by uninstalling something, but the problem is that I don't remember what it was... (I installed Exp.Web in fresh Win7 PC, and step by step installing everything, until this problem came up.)
Anybody came across this issue maybe ?
The problem is a program called FileBox eXtender. It's excellent program I use to pin windows to have them always on top (never be hidden by other windows), because it does its job and it's free. Unfortunately, MS-Expression (Web, Blend, etc...) doesn't get along with it, so I excluded it (somewhere in FileBox-eXtender's options) and now it's o.k.
We can’t just leave our customers that are not able to upgrade to windows 8 for a long time in the larch. However there is demand for a “tablet”/”touch” version of our app.
So how can we support both touch with Metro on Windows 8 and our current customers from a single code base?
When WPF come out, after a lot of “Pushing” Microsoft saw since and make it work on Windows XP – has anything like this been talked about for WinRT.
(I am not expecting any solution to work on XP, as XP support is being wound down.)
See Also: Can the ARM version of Windows 8 only run Metro (WinRt) style apps?
The best answer is that you do not want the same application to run on Windows 7 and Windows 8 Metro style. The UI that works best for mouse and keyboards (windows 7) will not work well for a touch-first presentation and visa versa. It is important to re-imagine the UI for the two different worlds.
That said, you have 2 options if you want to share a lot of the code:
1) Write it largely in JavaScript/HTML5. This will let you re-use many of the assets (especially the business logic parts).
2) Write it in (desktop) Silverlight. The Silverlight XAML is closest to Windows XAML. WPF is further away and will require more re-work later.
In either case, you should look at and follow the principles used when writing cross-platform code. Understand the platform dependencies and isolate them behind indirection boundaries. You want to localize all of the code that will have to change. For instance, you don't want calls to the .Net System.IO.File APIs which you know will have to change to Windows.System.Storage calls being scattered throughout your code. Instead, you want it localized in one function that can be modified later.
The only way I can think of is to implement your application in HTML5/CSS3/JS, and avoid using WinRT APIs inasmuch as possible - this may be feasible depending on what, exactly, your app needs to do (e.g. portable 2D graphics is easy with HTML5 canvas).
Then, for Win8, you'll package this as Metro web app. For Win7 and below, you write a simple app that embeds your browser of choice (not IE9, since it doesn't work on XP - so Firefox or Chrome) with all chrome hidden, and loads your HTML5 app inside that embedded browser.
As others have noted, you would not want to have exactly the same application working in Win8 Metro and Win7 / Vista Desktop. If you structure your application properly, using a suitabel design pattern, it is possible to share quite a bit of code between the various version that you would require. For the Win8 version, you will be using WinRT, for Win7 / Vista you have a choice of Silverlight or WPF.
I have published a couple of articles that demonsrate how this can be done, they include quite a bit of code as well:
XAMLFinance – A Cross-platform WPF, Silverlight & WP7 Application - while this article does not cover Win8, it does share code from WPF to Windows Phone 7, which is a very similar problem.
TweetSearch – A Cross platform Metro UI WinRT and Silverlight Application - this article shows how to use the same techniques to share code between WinRT and Silverlight
It is unlikely that we'll see Microsoft push the Metro-style
application framework back to past releases due to the level of
re-architecting that went into Windows 8.
I agree with Zac on this point. It appears Microsoft is definitely pushing both the technology and usability forward with the introduction of Windows 8 (and Windows Runtime).
The Metro UI is a different UI paradigm. If your using the current
Win32 controls (which includes WPF controls), your application will
look really dated in Metro. The only way to fix that is to
re-implement the UI (your View classes in an MVVM design) using Metro
controls. However, C# and majority of the .NET APIs are first class
citizens in this new environment. The rest of your application should
be fine.
As you already have what I assume a rather large application your best solution would be separate your view from your model-viewmodel. Then you can continue to develop both Windows 8 Metro full-screen touch-friendly awesome interfaces and the "classic" window interface (what we have done for the last x number of years). With good separation, design, and an excellent source control solution (i.e. Perforce) you will able to share a lot of the code base.
In addition to the answers given to your recent question on Windows Runtime Bill Wagner (one of the many C# bloggers that I follow) has posted summary on WinRT and managed languages conference sessions; it is an good read and recommended if you have a few minutes. One of the things that his summary clarified (in the FAQ at the end) was that the future of .NET as the branding for the framework we use is going to be replaced with Windows Runtime.
Another piece from Bill's blog post:
Some of the .NET APIs are changing for WinRT. I don’t have an
exhaustive list, and I’m not sure there is one yet. Other APIs are not
exposed via WinRT. (They are still available as .net APIs, just not as
Metro / WinRT APIs.)
It is unlikely that we'll see Microsoft push the Metro-style application framework back to past releases due to the level of re-architecting that went into Windows 8.
Like Pavel said, if you kept your application from using as much of the WinRT libraries as possible, it is possible but then again, you're now building a regular web app.