I've recently published a windows 8.1 universal app on the Windows Store. When I download it from the store on 8.1 devices, the first page of the app doesn't load correctly, some controls miss. On Windows 10 device, it works well.
If I put the app in the background and then recall it, the page loads correctly.
During the development, I've tested the app on several smartphones and I've never meet this problem.
Has someone met this issue?
In this capture, all controls are loaded
In this one, the checkbox is missing
I'm using the MVVM pattern without external package and I use the control Coding4Fun.Toolkit.Controls.Popup for displaying error messages.
Problem solved, it was a custom control who makes this bug. I use it on each of my pages and it works well. But when the app downloaded from the store starts, it perturbs the loading of the first page of the application.
I want to give user an option to restart immediately to apply different theme, using https://msdn.microsoft.com/en-us/library/ie/windows.ui.xaml.application.requestedtheme
Retargeting to 8.1 is not an option.
There is no way to programmatically restart a Windows Store app, and Windows 8 (as opposed to 8.1) doesn't support ThemeResources to apply theme updates to existing controls after they've been created.
You will need to tear down the existing visual tree and rebuild it, but there isn't a good way to do this on the existing page. The easiest way would probably be to navigate away and back.
I am developing a win store application, user can launch other file/application from my application. At that point, I want to keep my application in front of user in the "snap view"
For Windows 8.0, there wasn't a way to control this. In Windows 8.1, the Windows.System.Launcher API--namely the LaunchFileAsync and LaunchUriAsync methods that take a LauncherOptions argument--added support for the LauncherOptions.DesiredRemainingView property. This gives you the kind of control you're looking for here--in your scenario you'd want to use the value ViewSizePreference.UseMinimum in the DesiredRemainingView property.
I have a win form application and i'm trying to run it inside the web browser,i rummaged through web and found some links:
I tried this link:Embedding a .NET WinForms Application in an Internet Browser Using WPF
,this works fine but the problem is that the end-user has to install dot net frame work for running the application.
I found another link here for running a WinForms Application Inside Web Browser,with Visual WebGui development framework.
Has anyone had any experience with WebGui?
Well, Visual WebGui is web over ASP.NET. Its developing experience is the same/similar to that of Windows Forms using the Visual WebGui designer integrated into Visual Studio. You do your code behind just the same as you would on Windows Forms and the WebGui runtime transforms it into HTML5/CSS/JS.
The efforts needed to convert your Windows Forms application to a equivialend Visual WebGui web application will depend on the (3rd party / .NET) components used in your Windows Forms application. The Visual WebGui API is farily similar to that of Windows Forms, so in some cases you can add a few references to WebGui specific assemblies and then to a search/replace for a couple of namespaces. There are of course some differences, as these are two different platforms, but the developing experience is quite similar to Windows Forms.
winforms is not web. Web is Web.
Web means HTML + something (usually JavaScript, CSS and probably jQuery or such).
1 - If you need a web application, and want to do it with .Net, create an ASP.Net Application.
2 - If you need a Windows application (Desktop), create a WPF application.
3 - If you need a Windows 8 "Metro" style application (a.k.a Windows Store App), create a WinRT XAML application.
4 - winforms is completely useless. Forget that.
If your customers don't want to install any version of the .Net Framework, your only option is #1.
A winforms application will NEVER be a web application, regardless of any hacks you do to make it run inside a web browser.
an XBAP (WPF Browser Application) is also NOT a web application. It's just a regular WPF client application that does not have it's own window.
Edit:
If you did things the right way (that is, maintaing separation of concerns and putting application logic in Controllers or ViewModels instead of the horrible code behind practices most winforms developers are generally used to), It should not be that hard to reuse your application logic and create a new application (web or otherwise) while maintaining the Data Access and Business Logic layers intact.
I think this question is very similar to this one:
Is it possible to convert a WinForm to a WebForm in .NET?
As mentioned before, the only way to run the application "as is" inside a browser will be through the use of some activex control and that would require IE + .NET Framework.
There are tools that you can use to automatically migrate the application to the Web, but there will always be some manual effort involved and it won't be the same as building the application from scratch as a web app.
In my limited experience with Visual WebGui, it is pretty cool technology. In simple terms, as I understand it, you can use the Windows Forms development IDE to create an HTML5-compliant ASP.NET client/server web application... not just a web site or page, with a look and feel very much like a Windows forms desktop application. It does this by converting Winforms controls to jquery code on the client side, and stores most of the executable code on the server side.
I've used it to create simple applications for testing purposes, and there are a few caveats. First, to create a "pretty" website, you need to rethink the Winforms layout to make it web-like, with headers, sidebars, etc. It's a different paradigm, and users expect certain things on a website. The good news is that this adjustment can often be done fairly easy by simply manipulating controls; i.e. a Panel control can become a container for a sidebar or header. You can also create "themes", which are like skins for the controls to modify the appearance.
Another consideration is that events for things like popup dialog boxes behave differently in a web environment. In Winforms program execution halts until the user clicks an "OK" button or something. Within Visual WebGui, all the execution happens on the server side; thus, program execution would continue without waiting for user input. This can be handled by creating a Form.Close handler for the popup box though. But these kinds of differences need to be kept in mind.
You also must consider object layout anomalies. Visual WebGui does a good job generally of mimicking the Winforms WYSIWYG benefit: Objects normally appear pretty close on the webpage to where you put them in the environment. But this isn't always the case; you need to play around with object padding, margins, etc. sometimes to get the right layout. Still it is often much easier than tediously changing spacing with CSS or div objects.
Thinfinity VirtualUI allows you to do so by adding a small line of code to your C# application so it can then be accessed from any OS and device via an HTML-able browser.
https://www.cybelesoft.com/thinfinity/virtualui/web-integration-for-windows-apps/
I've used VWG but it's not really an option anymore. One option not mentioned here is WiseJ, a proprietary framework which is still under active development and support in 2022. And it is fairly straightforward to convert a WinForms app to WiseJ, or begin using WiseJ like you would WinForms.
They are located here: https://wisej.com
I have a Windows Forms application that does not include a title bar, and on Windows 7, the taskbar shows the value from AssemblyTitle, rather than the value from the form's Text property. How can I change this value dynamically?
Thanks!
From your comments, I think you're referring to the "jump list" for the program, which includes a program title (if you click on it, an additional instance of the program is launched). My understanding is that what you're seeing is the default behaviour for all applications, regardless of the visibility of the title bar on your Form.
I tried to change this on a program I was writing and came to the conclusion that (at least within managed code) it cannot be done - Win 7 takes the value of the FileDescription in the executable (AssemblyTitle is a proxy for this in Win Forms apps) and uses this. As far as I know, assembly attributes cannot be altered for a running assembly and I'm not sure Windows would notice a change and update the jump list even if you could do it.
There is a managed wrapper for the Win 7 API (the Windows API Code Pack), and although there is a class for manipulating Jump Lists, I found nothing within it to override the default behaviour for this particular aspect of them.
Edit:
Looking more closely into the native API (as opposed to the managed Code Pack wrapper), I couldn't find any functions but I did discover this MSDN blog entry. Just under the second diagram (which defines the application title as part of the "Taskbar Tasks" section) and the Windows SDK quote, there is a list of activities developers can perform and it includes the following:
As developers we have no control over
the Taskbar Tasks.
So it looks like it's just not possible - this section of the Jump List is controlled exclusively by the OS.