Hi Marc, Often greater resources does not create a better result. Designers are difficult beasts, and from what I can see, the WPF object model was not "designed for designer creation" -- whereas the VG.net object model was designed specifically for that purpose. If you examine the designer infrastructure of the past, and the new designer infrastructure in VS 2008 (Cider), you can see a) the past infrastructure was complex and b) the newer infrastructure is even more complex. We are working on a new designer infrastructure ourself, for a designer outside of Visual Studio, and we have been happy to eliminate a lot of the unnecessary complexity. Frank

check out VG.net: www.vgdotnet.com An animated vector graphics system integrated in VS.net

It is too easy to create anonymous new identities on CP. I am not sure what the solution is. check out VG.net: www.vgdotnet.com An animated vector graphics system integrated in VS.net

That site does not provide much information regarding .NET gadgets. It sounds very generic, and the samples are simple html interfaces. The [Ooey GUI blog](<a href=)[^], by one of the MS developers, may provide more information soon. check out VG.net: www.vgdotnet.com An animated vector graphics system integrated in VS.net

If you are interested in building .NET Gadgets, you might want to look at this calculator[^] and analog clock. I am still trying to understand if .NET will integrate well into the whole Gadget idea. check out VG.net: www.vgdotnet.com An animated vector graphics system integrated in VS.net

I believe one should never install any Microsoft beta of any product on any partition you need to use every day for development. They have a reputation for messing things up to the point where you need to re-install Windows, or the CLR, or your applications. Sometimes everything goes well, but you never know -- until several weeks later when all the problems have surfaced, and too late for you. Maybe it works fine for everyone except your particular configuration. Why take a chance? Build a new partition. check out VG.net: www.vgdotnet.com An animated vector graphics system integrated in VS.net

VG.net is designed for this type of application. The run-time engine is free. check out VG.net: www.vgdotnet.com An animated vector graphics system integrated in VS.net

I have been told that it is permissible to publish articles using Microsoft closed-source software, but it is not permissible to publish articles using other free closed-source tools, except under Product Showcase? Even if permissible it seems to be distasteful for most members. Is there any good place to post such articles, here or at another site? Also, my request for rates on the Product Showcase received no response. Thanks! check out VG.net: www.vgdotnet.com An animated vector graphics system integrated in VS.net

Please disallow anonymous comments on articles. Here I am speaking of not just "true" anonymous comments, I am speaking of comments made by anyone that cannot be traced back to a real name. It is very easy to create a temporary user id just to post a temporary comment. This would restrict comments to people who are willing to put their name behind the comment, and reduce abusive/garbage comments. This is especially important if you wish to increase the number of women who post articles on CodeProject. check out VG.net: www.vgdotnet.com An animated vector graphics system integrated in VS.net

The original question was, should Marc's articles be in the XAML category? Are they relevant? I would argue they are very relevant, and people should know about MyXaml. The second point was to get the reaction from people regarding the Mobiform position. They posted one article in the XAML category, that discusses their product in particular. There was no source code included. So Ron's argument seems untenable. check out VG.net: www.vgdotnet.com An animated vector graphics system integrated in VS.net

The "kludge" argument was directed at companies such as Mobiform that misleadingly claim to have an Avalon clone, that forwards calls to windows forms. MyXaml is decidedly not a kludge as it works with the Windows Forms object model directly. In fact it works with any object model. That is the strength. In fact Marc was working on xml serialization before he even heard of ms-xaml -- I believe his first article was published before he heard of avalon. check out VG.net: www.vgdotnet.com An animated vector graphics system integrated in VS.net

Except one. check out VG.net: www.vgdotnet.com An animated vector graphics system integrated in VS.net

As a result of Ron's complaint, all of Marc's articles were pulled from the XAML category. check out VG.net: www.vgdotnet.com An animated vector graphics system integrated in VS.net

What do you guys think? Are Marc's articles worthy? If you like Marc's articles you might want to post a response on the newsgroup. mobiform articles or marc?[^] check out VG.net: www.vgdotnet.com An animated vector graphics system integrated in VS.net

No, with .NET you cannot put your dlls into a CAB. Regards, Frank Hileman check out VG.net: www.vgdotnet.com An animated vector graphics system integrated in VS.net

I thought you were using the compiled types anyway, so I did not understand.

Just curious about the "expensive in terms of memory" comment. In one of our apps, we are generating code dynamically and compiling it, at either design-time or run-time, according to the user's requirements. Noticing that the codedom compiler was simpler than vsa, and allows C#, we used that. I noticed that compilation occurs out-of-process, except for jscript.net, even if you specify in-memory. If you force the compile into another process (in the case of jscript) the overhead seems to be entirely in time and not memory. Unless I am missing something. We had to allow run-time code generation because the user's object hierarchy might be built at run-time. Normally, however, the hierarchy is built, code is generated and compiled, all at design-time. If you are curious, the app provides a way to graphically connect objects to realtime data sources, for process control and similar purposes. The compilation is needed for expression evaluation, and to avoid boxing during data transfer. Regards, Frank Hileman

The answer to 3) really depends on the usage of the solution. Your state the scenario, but there are not enough details in that scenario to answer the question. Why put the source in the DB? Why not compile and store the binary at the same time? What will the binaries be used for? Will the process using the binaries be long or short-lived (the most important question)? How often does the source change? If you just throw away the process then there is no need for an appdomain infrastructure. Even if you build one, you may still see memory growing. I believe even unloading an assembly still may cause memory leakage -- I seem to remember a problem in the vsa newsgroup, anyway. Perhaps it is the string cache (interned strings). If the only sure-fire way is to use a temp process, your solution is simplified -- you only need remoting. So you can look at the appdomain stuff as an optimization, and it may be you are optimizing something which does not need to be optimized. As I said, there is not enough info in your scenario to say exactly what is important. For myself, I was thinking of a .net interpreter. Mainly for testing. It is very useful to have an incrementaly constructed environment for testing. Sometimes you don't want to write a whole program to test one function. You want to type something on a command line or use a gui and have the function tested. NUnit etc. are nice, but they are really for automated testing. To test interactively you need an interpreter, that can create typed variables, and can pass the values of those vars to functions, using a commmand line or a gui. An interpreter, as I envision, would have to be able to do some run-time compiling, at least of expressions and functions. Command-line or gui variable assignments can be done with reflection, but expression evaluation must be very rich, as rich as a .net language, so you need a full-blown compile. If nobody does it I will do it someday. As I said, it is a time saver. In such an environment memory will be wasted (all the little dlls created each time a change is made to an expression). But it does not really matter. Regards, Frank Hileman

It is now months since you posted this message. I hope you read this. Answers: 1) yes 2) not usually 3) no, not necessary. An interpreter you describe is very useful for testing. If that is the main purpose, memory leakage is not so important. Far more important is the user interface -- the command-line, or GUI. Regards, Frank Hileman