I'm BRAND NEW to the whole C#/WPF thing. I have a decent understanding of the concept of the WPF layering and it is a very nice tool. What I am running into, however, is that VS and the like try to make things very hands-off as far as the underlying code.
When firing up a brand new WPF application in VS C# Express 2008, there are two immediately visible source files: App.xaml and Window1.xaml. This is all fine and dandy, but the only place I see any significance of where things start is the line in App.xaml that says
<Application x:Class="SomeName.App"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
StartupUri="Window1.xaml">
Looking into the class name of SomeName.App, I'm guessing that extending Application signifies that as where to start, but how does the application actually know that?
I am quite familiar with Java, so if it makes things easier to explain that way, please do. I like to understand things at the lowest level possible (without getting into machine code), so please help me get a bit deeper into the inner workings of C# and the WPF.
As always, thanks to the StackOverflow community for any help. :)
The concept you probably need to understand is that the tool-chain generates code from XAML files, which gives 'code-like' behaviour to the declarative XAML.
But WPF is pretty complicated and not much like anything else, and a book might be useful - personally I think the Adam Nathan WPF book is excellent, and will cover this "general understanding of the concepts" stuff much better than the Internet, IMO.
The generated app file will probably be called app.g.cs, and will be in one of the intermediate file directories - have a look in there to see the actual startup code - among other things, you'll find something like:
public static void Main() {
MyAppName.App app = new MyAppName.App();
app.InitializeComponent();
app.Run();
}
at which point it may start to make more sense.
In fact, you can write all that startup code yourself if you don't like the declarative route.
Related
I am trying to write a VST Host which basically should provide a better interface to control to Plugins at the same time. For that i looked searched for the best way to do it and stumbeld over VST.NET. Now i made this code to just simply open a plugin:
HostCmdStub cmdstub = new HostCmdStub();
VstPluginContext cont = VstPluginContext.Create("C:\\Program Files\\..\\Turnado.dll", cmdstub);
Logger(cont.PluginCommandStub.GetProductString());
cont.PluginCommandStub.Open();
(Code for the HostCmdStub taken from https://github.com/perivar/AudioVSTToolbox/blob/master/ProcessVSTPlugin/HostCommandStub.cs)
The Looger correctly logs Turnado so the dll seems to be loaded but nothing opens.
I don't really have any experience with VST.NET and my C# knowledge is also not that fresh. (If I could i would write the host in something like Java but there seems to be no good way to do so...also it seems not a good idea performance-wise).
Is there an obvious problem with my code or even a better way to create a host...I might even switch Programming language as i'm not that invested in the c#/VST.NET project yet.
This might be more of an outcry, but building DataTemplates in Silverlight code seems to be impossible. The one option I am aware of being using XamlReader.Load(string), one is met with several issues using this approach:
No validation, everything is done in concatenated strings. We all know this sucks
Any necessary resources have to be included, as this will run in its own context. This also sucks, although there is a logical explanation and not a show-stopper.
Any attempts to include event calls inside your DataTemplate will fail with InvalidOperationException: Invalid XAML for control: XamlReader.Load() does not accept event handlers.
No.3 seems to be a show-stopper for me. I would appreciate it if anyone gave some clues, pointers or ideas towards another / better way of doing this.
In WPF there is a FrameworkElementFactory that can provide assistance, however there seems to be no remedy for this in Silverlight.
Maybe you dont need to build datatemplates in code. Do you really need to do that?
(#2) You dont need to include the xaml resource. it could reside remotely somewhere. all you have to do is load it remotely. But maybe im not understanding what you said.
I have a .dds file and I want a .png file. Although I already found out about the DevIL.NET library, the API design there of one static class does not parallelize, so I am hoping to find another method. This led me to XNA.
But, here's how far I got with that idea...
OK, it looks like I want this Texture2D class; then I can call myTexture2D.SaveAsPng.
But how do I get one of those from my .dds file? Well the documentation seems to indicate I want to use myContentManager.Load<Texture2D>.
Oh crap, that wasn't it, that's some kind of game content management system. Well, my searching seems to have turned up a lot of uses of myTexture2D.LoadFile; I'll go for that.
Uh am I missing an assembly reference or something? Oh no, I get it, they removed that method between 3.1 and 4.0, awesome. OK, well, it's a bit more annoying, but myTexture2D.LoadStream isn't really a problem.
Wait what's this now? It wants a GraphicsDevice? Hmm it looks like one usually gets one of those via a GraphicsDeviceManager... oh wait, I'm not going down that path again, no more Managers for me.
I guess I'm supposed to instantiate this thing manually. OK well this isn't too hard... var myGraphicsDevice = new GraphicsDevice(GraphicsAdapter.DefaultAdapter, GraphicsProfile.HiDef, (uh oh what is this PresentationParameters thing well OK I'll just try new PresentationParameters());.
Well that threw an exception. They want... a DeviceWindowHandle in my PresentationParameters? BUT I'M RUNNING A CONSOLE APP!!
So I'm really hoping there's a less convoluted way of doing this; perhaps some kind of default GraphicsDevice I could use. It feels pretty silly to create a whole window just to convert .dds to .png.
Alternative suggestions for my conversion problem welcome, I guess, although it would probably be worthwhile to understand how to use XNA from non-XNA code in general.
If you have a command line app that needs to create an XNA graphics device, the code in this answer should be of some assistance.
In a nutshell, you need some of the classes from the WinForms sample to avoid having to mess around creating a graphics device services and so on (specifically the classes ServiceContainer and GraphicsDeviceService).
Then you can do this:
Form form = new Form(); // Dummy form for creating a graphics device
GraphicsDeviceService gds = GraphicsDeviceService.AddRef(form.Handle,
form.ClientSize.Width, form.ClientSize.Height);
ServiceContainer services = new ServiceContainer();
services.AddService<IGraphicsDeviceService>(gds);
content = new ContentManager(services, "Content");
Tada - now you have a working ContentManager that you can use to load stuff. I believe you should be able to get the actual GraphicsDevice from the GraphicsDeviceService, too.
The form you create is never displayed. Remember to reference System.Windows.Forms.dll in your project.
Disclaimer: This was written for XNA 3.1. I haven't tested it in 4.0, but I suspect it will work with little or no modification.
From the top of my head (haven't used XNA for a while):
Conversion of datatypes is not a common scenario for XNA. It expects to get all assets preprocessed by the content pipeline.
XNA expects the graphics device quite often, windowless applications are out of XNAs scope.
It seems to me that you are using the wrong tool for the job, although I couldn't tell another one except DevIL, which you already dismissed.
Creating a call stack diagram
We have just recently been thrown into a big project that requires us to get into the code (duh).
We are using different methods to get acquainted with it, breakpoints etc. However we found that one method is to make a call tree of the application, what is the easiest /fastest way to do this?
By code? Plugins? Manually?
The project is a C# Windows application.
With the static analyzer NDepend, you can obtain a static method call graph, like the one below. Disclaimer: I am one of the developers of the tool
For that you just need to export to the graph the result of a CQLinq code query:
Such a code query, can be generated actually for any method, thanks to the right-click menu illustrated below.
Whenever I start a new job (which is frequently as I am a contractor) I spend two to three days reading through every single source file in the repository, and keep notes against each class in a simple text file. It is quite laborious but it means that you get a really good idea how the project fits together and you have a trusty map when you need to find the class that does somethnig.
Altought I love UML/diagramming when starting a project I, personally, do not find them at all useful when examining existing code.
Not a direct answer to your question, but NDepend is a good tool to get a 100ft view of a codebase, and it enables you to drill down into the relationships between classes (and many other features)
Edit: I believe the Microsoft's CLR Profiler is capable of displaying a call tree for a running application. If that is not sufficient I have left the link I posted below in case you would like to start on a custom solution.
Here is a CodeProject article that might point you in the right direction:
The download offered here is a Visual
Studio 2008 C# project for a simple
utility to list user function call
trees in C# code.
This call tree lister seems to work OK
for my style of coding, but will
likely be unreliable for some other
styles of coding. It is offered here
with two thoughts: first, some
programmers may find it useful as is;
second, I would be appreciative if
someone who is up-to-speed on C#
parsing would upgrade it by
incorporating an accurate C# parser
and turn out an improved utility that
is reliable regardless of coding style
The source code is available for download - perhaps you can use this as a starting point for a custom solution.
You mean something like this: http://erik.doernenburg.com/2008/09/call-graph-visualisation-with-aspectj-and-dot/
Not to be a stuck record, but if I get it running and pause it a few times, and each time capture the call stack, that gives me a real good picture of the call structure that accounts for the most time. It doesn't give me the call structure for things that happen real fast, however.
With our next major release we are looking to globalize our ASP.Net application and I was asked to think of a way to keep track of what code has been already worked on in this effort.
My thought was to use a custom Attribute and place it on all classes that have been "fixed".
What do you think?
Does anyone have a better idea?
Using an attribute to determine which classes have been globalized would then require a tool to process the code and determine which classes have and haven't been "processed", it seems like it's getting a bit complicated.
A more traditional project tracking process would probably be better - and wouldn't "pollute" your code with attributes/other markup that have no functional meaning beyond the end of the globalisation project. How about having a defect raised for each class that requires work, and tracking it that way?
What about just counting or listing the classes and then work class by class? While an attribute may be an interesting idea, I'd regard it as over-engineered. Globalizing does nothing more than, well, going through each class and globalizing the code :)
You want to finish that anyway before the next release. So go ahead and just do it one by one, and there you have your progress. I'd regard a defect raised for each class as too much either.
In my last project, I started full globalization a little late. I just went through the list of code files, from top to bottom. Alphabetically in my case, and folder after folder. So I always only had to remember which file I last worked on. That worked pretty well for me.
Edit: Another thing: In my last project, globalizing mainly involved moving hard-coded strings to resource files, and re-generating all text when the language changes at runtime. But you'll also have to think about things like number formats and the like. Microsoft's FxCop helped me with that, since it marks all number conversions etc. without specifying a culture as violations. FxCop keeps track of this, so when you resolved such a violation and re-ran FxCop, it would report the violation as missing (i.e. solved). That's especially useful for these harder-to-see things.
How about writing a unit test for each page in the app? The unit test would load the page and perform a
foreach (System.Web.UI.Control c in Page.Controls)
{
//Do work here
}
For the work part, load different globalization settings and see if the .Text property (or relevant property for your app) is different.
My assumption would be that no language should come out the same in all but the simplest cases.
Use the set of unit tests that sucessfully complete to track your progress.