I'm working on an XNA project, for the Xbox 360.
For this I have built an extensive UI library, all with relative positions, dozens of controls and stuff like that.
At the moment of speaking, all the design elements are created in page classes, which is a lot of code (think of margins, aligns, labels, and so on).
So I was thinking, shouldn't it be possible, to create a file, like a XAML file for example, and using C#, parse it to objects?
XNAML uses this kind of approach (I think), so I know it must be possible, I'm just wondering how. I could go with the approach of parsing the file manually line by line, and creating every object, but I think this would be pretty complex & nasty code, considering the amount of different objects. Any input is greatly appreciated!
F.Y.I., XNAML is deprecated (I even think it never went live)
Related
I am learning the ins and outs of Entity Framework right now and being a practical learner I just wrote some simple examples of the kind of stuff that I'm looking at in C# and went through the classes in Visual Studio's Object Explorer ("tooltip").
This is however quite confusing at times and I was wondering if I can't just print out the stuff that I have and look at all of it at once.
I tried using Newtonsoft.Json but it tells me it can't deal with that kind of data because of "self referencing loops" and stuff, which I guess makes sense, considering the type of objects that I'm looking at .
Is there a way to enumerate the different kinds of ItemCollections (EdmItemCollection, ObjectItemCollection, etc), MetaDataWorkSpaces, and what else there is, and print them out? Or am I forced to go back to theoretical learning?
You should use a watch.
It allows you to look into the object structures while debugging.
It works better than the tooltip, and navigation is quite easy.
I'll be blunt. I miss XAML. I also miss DataBinding and markup that actually makes sense and is consistent in the naming of its properties. When it uses camelCase, it sticks to it, unlike android markup, which just does some properties with a _ in between words, and others without it. It's a nightmare to handle without autocompletion.
Or at least, is there any way to omit the android:namespace? Writing it for each argument is torture. I'd go with just a: but I'm wondering if there's an easy way to skip it entirely.
Are there any third-party tools to make this less troublesome?
Unfortunately, this is not currently possible while working with Xamarin. There are a few solutions when working with Android in AS but in XS or VS so far there's not another way to do it unless you define your views in code.
I am currently trying to develop a small simulation program in xna that takes a model and breaks it up into several smaller pieces.
The only way I was thinking would be to take the original object, copy it, then remove a chunk from one (using a pre-built model) using subtraction boolean, then perform an intersect boolean operation on the other, and presto, two objects which together look like the original, but can be separated individually.
The only issue is, I have no idea how to do it, or if it is even possible.
I would prefer to use XNA, but I'd be open to using any other free/open source 3d engine if anyone knows how. Preferably something with a nice simple .net wrapper, but probably not.
Robust boolean operations on solids are outside of the scope of a graphics engine like XNA.
One I've used before is open cascade
A lot depends on the complexity of your models. Maybe opencascade is overkill for what you are trying to accomplish. It is intended for CAD environments.
I found this old sourceforge project, which might help:
http://sourceforge.net/projects/djxcbo/
I need to visualize a graph. I don't know how to name it (by the way, if you know - I'll appreciate if you tell me). It would be ideal for graph elements to be clickable (so that when user clicks on a block, I can handle an event with the element id specified) but I can survive even without any interactivity. I may like to be able to focus on a particular node and layout all others to view from its perspective. Are there any components available good for this task? If no, what should I look for to help me to develop an algorithm for drawing such a graph with visually-comfortable layout?
Practical nature of this graph is pretty common: each block represents a derivation from 2 operands. Orange circles are references to 2 operands, green circles are connection points to consumers. It can be significant to distinguish an operand position (left or right), for example if a derivation represents a mathematical operation of difference or division (in this particular case a block can be triangular, but in other cases an operand itself can make use of being aware of for what blocks is it a left operand and for what blocks is it a right). Another common application is intersecting sets with complex relations.
You could take a look at Graph#, but I'm not sure how well it'll handle composite nodes like that. It could be a good starting point though.
I also would like to point you to graphviz. It is not a .NET solution but you can feed it files that are easy enough to write in order to create graphs. I don't think layouting is a very simple thing to do, especially with increasing node count, so it should be a good thing to find some tool for that.
As It seems Microsoft itself has done a really good job on graph visualization called automatic-graph-layout.
Here's the link https://github.com/microsoft/automatic-graph-layout.
Well, you first need to represent it somehow in memory, there are many ways, like adjacency list. Then you need to draw it. While generally drawing a graph is simple, it's not that simple if you need to layout it. Looks like in your case, that's exactly what you need to do to come to that nice representation. It ain't going to be easy.
EDIT: Interesting, there seems to be a library made by Microsoft Research.
I don't know how useful it will be in this particular scenario, but you might want to take a look at http://quickgraph.codeplex.com/
Graphviz4Net provides WPF component for graphs visualization. It depends on GraphViz (open source command line graph visualization tool).
I can not find this component and i decided writen my own control, line and head, and use them to visualization my graph's
If the needed your i can give it's component and program to demonstrate him/
I writen component and program's in visual studio 2008 language C#
This is a fairly new and maintained .NET wrapper for Graphviz: https://github.com/Rubjerg/Graphviz.NetWrapper
(Disclaimer: I'm the author)
This wrapper works differently from other wrappers, since it makes direct function calls to the native Graphviz code. This means you can not only programatically construct your graph in C# code, but also read the layout attributes back out in C# code and render it any way you want. The latter sounds specifically like something you would be interested in.
A quite good looking one is the Diagram tool from Nevron. But it's not for free!
I'm currently using the charts and user interfaces from them and they work quite good.
Have used this commercial product with success: GoDiagram
It support the multiple ports on the nodes like you have shown.
I am trying to determine that if (before I start) on a new project I can pick some suitable patterns which will help with development as the project gets more complicated.
The Scenario
To have an application that draws 'simple' lines on the screen. Ideally encompassed into a 'Render Engine' which I can package into Silverlight, WPF demo applications etc.
I also require editor application that uses the render engine to do the bulk of the displaying, however provides additional functionality like control points for moving the lines about the screen & Dialogs for changing the colours of the lines etc.
The Goal
To keep the render engine specalised and efficient. The editor should be able to 'inject' the additional functionality (i.e. display of control points) into the objects used by the rendering engine, or into the render engine itself. I don't want to code any editor specific code into the render engine.
My thoughts so far
I'm thinking of using an encapsulation/template pattern for the objects that will be used by the rendering engine, somehow allowing the editor application to supply a class to the object which 'tacks on' the functionality for the control points (and for example the event handling for moving of the control points).
My reason behind liking this idea is that the rendering engine never need know about the environment in which it is working. The editor can be changed extensively without ever having to change the rendering engine (hopefully).
But....
I may be wrong, if anyone can see any pitfalls, or has experience of better ways to tackling this problem I would love to hear them!
I agree with Charlie that you should start with a simple design prototype and extend it as needed (that's how I started with my map rendering engine). I can give you a few suggestions though:
Separate the drawing engine from the rest of the code (here's an example how). By the drawing engine I mean the code that actually draws something on the screen/bitmap. It should consume drawing primitives, not some higher-level entities. This way you'll be able to switch the drawing engine easily (example: SVG, PDF, GDI, WPF...)
If you want to have an editor, one of the patterns that are useful is the State pattern
Well shoot, that's an impressive amount of forethought.
My philosophy has always been, use a design pattern when you need to use one. Otherwise you may become an architecture astronaut, designing grand schemes all for naught. It's good that you're thinking about design before development, but really, how much can you possibly know about the project before any code has been written? Just about nothing. And if you force yourself into a pattern before any code has been written, you may end up jamming a square peg into a round hole for the entire lifecycle of the application.
My advice to you: write a prototype first. Quick and dirty. No real design; just make a skeleton that walks. Learn from it. If you thought of a better way, scrap the original and redesign a new one. Use design patterns that make sense as you add functionality, not for the sake of adding functionality.