We are building a pretty complex application using C++/WinRT, with the plan to transition to WinUI down the road. The application has various places where it needs pretty comprehensive and sophisticated table view functionality.
Ideally we would use a C++/WinRT "native" table view, but there doesn't seem to be such an entity.
We have briefly researched the possibility of embedding a Windows Community Toolkit DataGrid under a "C# Island", but we are looking for other options or better paths forward.
What are the current best practices for supporting powerful table views (lots of rows and columns, sorting, column reordering, inline editing, etc.) in a C++/WinRT application?
Related
I am making a web browser made in VB.Net, and I do have people using it from around the world, but I don't think all of them can understand everything it can do. Does anyone know how to create a sort of language pack that users can change the language of every label on the form? The only way I can think of is editing all the labels to another language, then publishing the application again, but that is a lot of work because I do use a lot of labels... any help would be appreciated. Thanks!
What you're looking to do is called "localization." While localization itself is not a difficult topic to understand, depending on the complexity of your application, and the number and diversity of languages you want to support, it can become a rather involved task.
The general concept behind localizing an application is separating translatable elements (like all of the strings in your buttons, labels, and menus, or any images containing words) from the application itself, and storing them as resources which can then be chosen appropriately based on user preference or region, and then loaded into the application dynamically. There are a vast number of ways to accomplish this, and which you choose is entirely up to you, and how much effort you're willing to support. Techniques can range from loading strings from text files, storing and retrieving resources from a database, to using .NET's built-in localization functionality which stores assets in external resource files.
Localization as a topic is incredibly broad, so there is no single method that can be discussed without first knowing your specific goals and constraints. Your best plan of action is to start researching, and find a technique which seems most suitable for your project.
Google: ".net localization"
I want to create a web-based flowchart to source code translator.
My problem is I don't know what specific flowchart making tools/framework/API to let the user create dynamically a flowchart using basic flow-charting shapes that can be later translated to a particular programming language source code.
I'll be using only the basic shapes of flow-charting since this flowchart to source code translator will be used preferably to aid the learning of a novice programmer.
If this is in a commercial scenario, using a commercial graph drawing library like yFiles should be feasible.
With this library you can create your own flowchart editor:
you can declare and create your own specific shapes and behaviors
drag and drop, as well as interactive modification and creation of elements is supported
you can add logic to prevent the user from making certain connections (like connecting the end node to the start node)
the editor supports automatic snap-lines so that creating a nice diagram is made really easy.
you can use automatic layout algorithms to rearrange the diagrams and/or the edge routings to get nice flowcharts where the information flow is nicely depicted (going from top to bottom or left to right, e.g.)
Take a look at this interactive set of demos (requires HTML 5 capable browsers) and especially this one. The latter shows the drag and drop feature, the automatic layout using a style that is great for flow-charts and the snapping and some more advanced features like grouping and partition grids.
Disclaimer: I work for the company that creates that library. There are other libraries (although not as powerful in my humble opinion). I do not represent my employer on SO/SE.
I'm writing my first WinRT app for Windows 8 in C#/XAML managed code and I obviously have to handle the UI in the different sizes and orientations that could occur (FullScreenLandscape, FullScreenPortrait, Filled and Snapped).
Most people seem to suggest handling the UI changes through the Visual State Manager in XAML, however me being more comfortable with writing the code-behind rather than XAML, I thought I would simply handle the Current_SizeChanged event with a switch statement for each of the states.
I tried both ways and both seem to work for me (though the VSM was decidedly more work - at least for me).
Can someone tell me why I should use the VSM over code, or what benefits I would receive?
It's a good question, and certainly one that entered my head when starting WPF & WinRT development. Having coded C# projects for years, it seemed a strange concept to start building UI logic in the Xaml (which is usually more lines than C#, but also more declarative).
In actual fact (if you don't mind me saying) I think we can abstract your question out to 'Is there any benefit to writing UI code in Xaml over C#/VB.net?'.
Let me give you an example, in work I'm on a project team with several developers, and several graphic designers. The designers are pretty awesome at laying out that Xaml, and creating a consistent feel for the application (something I can't say I would be that good at) - but will have little idea when it comes to writing web-services and Data Access layers - which is our job as developers. And that's how it should be right?
Well whenever you start writing a lot of View/UI related logic in C#.net, this can lead to all sorts of problems. The designers all of a sudden can't focus on the Xaml at hand, and must get up to speed with OO programming. In our project this isn't that much of a concern, as the designers are actually pretty competent developers (must have been all that UI code I forced them to understand last year :)) But what I think it boils down to is a 'Separation of Concerns' at a job description level. If we take the paradigms associated to WPF I think things like Databinding 'guides' developers down a road where they create separated, testable UI and Business layers - the same way that the nature of Xaml allows for a very declarative approach to writing UI where the View Logic is created and maintained in a very readable manner without getting too much into the nature of OO programming.
So, coming back to your question - No, I don't think there any immediate benefits, and if you come from a mainly .Net background to write a lot of these things is Xaml can be little tricky. However, if you are in a team of people - or if you find best-practices a very important factor in development, then writing View related code such as Visual State manager configuration in Xaml is the way to go.
One last point - you'll notice I used the terminology 'View related logic' a lot. This is because it's widly viewed that writing UI related code in code-behind is acceptable (if not best-practice) but sometimes due to the nature of the WPF or WinRT framework you are dragged down this route for some functionality. However, if you are writing business logic in the UI files codebehind this is viewed a particular no-no. This breaks the 'seperation of concerns' and can make testing very difficult. If you are following the MVVM pattern (as many WPF or WinRT projects do) then this is what the ViewModel is responsible for.
I have many Normalized tables - might be more than 50... I was wondering what is the best approach for defining ViewModels - individual ViewModel for each form or making Common ViewModel for multiple Forms. Because making individual forms might increase the size of the data that needs to be downloaded and it might increase the redundancy of data on the client. i.e. using Category on each form has different set of data for each of them. and On the otherside making common viewmodel for set of Forms might increase the complexity in managing stuff.
Is there any proper article describing such aspect of Development. What is the best practices for managing overall Application so that it will offer optimal performance. (Fetching minimum Data from Server)
Thanks for your time and help.
The amount of views & models will increase the size of your XAP file, which is downloaded completely on open, this can be compressed. Actual performance during use is different and depends on other factors as well, try using SilverlightSpy to get an idea of actual browser performance. It is possible to download parts of your silverlight app as required, but this is an advanced technique.
If Messaging is your main concern, then check out Binary Messaging.
I recommend using a new ViewModel for every view, or nested Usercontrol, then use an event aggregator for communication between models.
Typically you'll want to create a View Model for each View. If two Views display the same data and allow the user to perform the same actions but differ only in UI implementation then they can share a View Model but the goal is to keep your View Models cohesive. If your View Models contain code to operate multiple views you run the risk of implementing the "God Object" anti-pattern. If you find that your View Models all share a certain amount of common code, consider moving that code to a common base class.
Remember that two completely different View Models can manipulate the same Models. This might be the case if two views display the same data but each allows the user to interact with it in a unique way.
I would highly recommend reading Pro WPF and Silverlight MVVM by Gary Hall. It's a great book to get started with MVVM, particularly for use with WPF and/or Silverlight.
i'm assigned to research something about how to use “addons” on building a program.
Basically, I have one main program that checks for the available components (ocx, dll, etc). Depending on what components there are, it will dynamically create the menus and load the components.
is this possible using .net Framework 2.0 or later
I think you might be looking for the word "plugin" and it is definitely possible with .Net.
For example: http://www.codeproject.com/KB/dotnet/PluginManagerClassBrk.aspx
One thing you could check out is the Microsoft Enterprise Library "Composite UI Application Block." This framework is designed to help build GUIs by combining separate UI components by composing them together based on various conditions.
I'm not sure if I'm a huge fan - it's pretty complicated and seems clunky to work with, but if you work through some of the examples, it might be worth looking into.
http://msdn.microsoft.com/en-us/library/aa480450.aspx