steved

Well, this is just peculiar. I received a forum email from PlausiblyDamp recommending using Divil's docking controls (divil.co.uk). It doesn't appear to show up in the actual forum, though. ;) While I have downloaded and looked at his libraries in the past -and they are excellent- they don't exactly suit my needs. I need a 100% open source solution - preferably using a license as flexible (or moreso) than the LGPL. The GPL won't cut it, since I'd like to share this code with the MonoDevelop project, which is currently licensed under GPL/LGPL/X11 in different areas. For similar legal reasons, code derived from anything supplied by Micrsoft is also not a solution; I would, however, still be willing to look at it even if I didn't use it directly.

Hmm. A quick reply to myself: I seem to have found something along the lines of what I'm looking for. It doesn't work for me yet (compiles fine, shows nothing), but it looks like a good place to start. I'd still love to hear other comments on this, however. The VS.net Property Box hook would be a great thing to have. :) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vstchfaqaboutvsnetautomation.asp

Hey there. I'm wondering if anyone has run across any source that would produce a control capable of docking in Visual Studio within an addin. Specifically, I'm looking for 3 things: 1) A toolbox which can dock on the left with the standard Toolbox (or within it) and Server Explorer 2) A canvas for the main viewport, equivalent to the Windows Forms Designer. 3) A dockable properties box. I would prefer to just hook the standard Visual Studio properties box for this, however. In case you're wondering what I'm doing, I am currently building a GTK# (the mono/GTK+ equivalent of .NET System.Windows.Forms) Form Designer as an addin for Visual Studio.

If you need to ask this question, you probably have some exploring to do before you tackle a map editor. ;) I would recommend puttering with GDI+, then having a look at directx4vb.com (or any other tutorials around this forum) to get a start on that. You won't be able to treat the entire map as one giant image. At 16,500 px^2, your RAM consumtion would be nuts. You'll probably want to keep your tiles loaded in some sort of surface and draw the currently visible area off of those. If you have a bunch of tiles, you'll probably want to separate them out into map type or something, so you only need to have the relevant tiles in memory at any given time. But I digress: Experiment with GDI+. It's easy. Then work your way up.

Probably a wise idea. Although 2003 was a "C++ release," much in the same way that 2005 will (unfortunately) be a "VB release," there were plenty of C# changes between 2002 and 2003 to make buying it worthwhile. I cringe when I have to use 2002. :)

KenpoMatt, I have to agree with techmanbd. Oracle is a beautiful piece of software from an engineering perspective. Granted, MSSQL is cutesy-poo and ridiculously easy... but if you have any fulltime DBA staff, that really isn't an issue. Don't get me wrong, I like MSSQL 2000 a lot (mostly because I'm no DBA). I just like Oracle9i more. ;) Now with Oracle 10g out, I'm curious if Yukon will do anything to tackle grid computing, or if Microsoft plans to keep its nose out of the high-end enterprise market. Anyone else read up on what treats Yukon will give us? Or, better yet, did anyone go to PDC2003? No one from my office was willing to shell out $4000+ to fly down.

If you haven't been there yet, http://directx4vb.com/ is a great place to start. It probabl won't help much with opening of .X files, but it's a very thorough and straight-forward way to learn simpler tasks.

Thanks, Rosecroix. Definitely handy. :)

Right. And any sort of DirectX namespace in Mono would almost inevitably be some sort of OpenGL wrapper. I've heard a few OSS guys talking here and there that they planned to implement an open source DirectX API, but I have a feeling they are being somewhat naive in terms of the challenges that would entail (or impossibilities). However, a DirectX namespace in Mono (acting as an OpenGL wrapper, much in the same way Java3D does for both Dx and OpenGL) would make .NET even more impressively cross-platform. I am, of course, not deluded enough to think that anyone will be tackeling this soon. ;)

I don't think that DirectX9 is all that badly documented at all. I find the C++ docs more than adequate. Managed DirectX, in particular, is quite another story. But that's not what you asked. ;) To shed some light on the situation: I was talking to a very knowledgable MS project manager at a VS.net/Server2003 launch a few months back, and his explanation of MDX was that it existed purely to introduce C# and VB.net programmers to the world of .NET. Microsoft doesn't really have a lot of interest trying to market MDX as a platform for game development (which accounts for the majority of DirectX use). Those programmers who find MDX useful can migrate to C++, or they can figure out how MDX works using the C++ docs. That said, I think Managed DirectX is a really beautiful example of what can be done with .NET. "Classic" DirectX isn't always pretty to program, and I think MDX allows for some really simple and elegant code. And who knows. If people start to make legitimate use of it, maybe Microsoft will look at it more seriously. And then maybe de Icaza will put a DirectX namespace into Mono? :) Well, it's a nice dream, anyway...

That still seems to point to C:\WINDOWS\System32\, which is where MsiExec.exe is located. Thanks for the idea, though! :)

Unfortunately, no. The best I can come up with (for the time being) is to prompt the user with an "Open File" dialog when the time comes to find the location of the setup files. The Open dialog always seems to go to the correct location (the CD-ROM drive, in most cases), where setup.exe was run. This would imply that my little Installer class knows where its parent was run from - now we just need to figure out how to get that information. :) If anyone else knows, I'd still love to hear. If I find a solution elsewhere, I'll follow up in this thread.

Hey guys, Anyone have any idea how to find the startup path of a Setup Project executable? I need to know this in the Install() function of an Installer class within the app itself. Application.ExecutablePath returns "C:\Windows\SYSTEM32\MsiRun.exe" (or something similar), because by the time I've reached the Install() function, I'm already within the MSI installer program - I believe. I any case, I have this scenario: A CD (though it could just be a directory) containing the setup.exe, my .msi file (which contains the actual app - this app contains the Installer class), and a script I would like to run from inside Install(). Since the .msi run by MsiRun.exe is actually in the same directory as the setup.exe, finding its location would also work. Any ideas?

Feel free to post it, it might give me a clearer idea of how our code is differing. From your description, I'm confused as to what could be going wrong. (Sorry for the late reply - haven't been on in a while. :) )

elikakohen, I feel your pain - Managed DX swap chains are no fun. The C# project I spoke of earlier in this thread is GPL'd at: midget3d.com. Download the source and have a look at DeviceManager.cs. It's a tad archaic due to Ryan's firm belief in building everything with design patterns (which worked out really well for us, in the end). If you have any questions, feel free to ask. Also, if you feel you could improve Midget - our feelings won't be hurt if you send us some code. ;) Good luck!

Hey, no prob! I'm glad it helped. I'll be sure to let Gabe know his first-ever GPL code already helped someone. :)

Gabe, a buddy of mine, made a nice clean C#/Interop library that does the trick for this (BMP to codec or raw AVI). Another fellow was having similar trouble, so check the result in this thread: http://www.xtremedotnettalk.com/t75894.html (Sorry for the re-post. I just don't want people finding this thread unfinished.)

Sorry it took so long. He wanted to add an example app before making it public. I haven't looked at this version yet, but he tells me it still uses all P/Invokes of the vfw API stuff, there is no comments, and to give him credit for blah, blah... :) Have fun with it. I think Gabe (the guy who wrote it) will be updating it as he makes improvements, so let me know if you have any trouble. Good luck! http://midget3d.com/gabe/AviLib.zip

I was struggling with a similar problem in C# (the bmp-to-avi thing, not the rest of it). I have a friend who came up with a solution and is now making a go at wrapping up that entire API. I will post his C# code when I can get ahold of it - hopefully that will help.

Ha! A fully-featured app is probably a long way off, but thanks mutant. :) Compile in VS 2002 As for the 2002/2003 issue, all you need to do is follow the directions on the main page to get rid of all the 2003-dependant project files. If someone knows a better way to "revert" vs2003 projects back to vs2002 format, please let me know. The other (and better) alternative is to use the free 'csc' .NET Framework 1.1 compiler. This is a bit cumbersome, though, since there is 3 separate assemblies/projects to compile. Running only the binaries ThePentiumGuy, if all you are interested in doing is running the program, it's a 3D modeling/animation package that can generate a series of bitmaps or create movies (AVIs) from your 3D models, keyframes, and dynamics. To run it without compiling, just download the source code and binaries and run the binaries from the /bin directory. Don't forget, MDX apps need the Managed DX DLL's as well, which are the last item in the downloads list. Comments and such Since this was a 4th year University project, we tried to keep the code as commented as possible. However, you'll no doubt notice we missed a few spots. :) That, and Conrad enters comments such as: // I am listening to rap. Ryan and I will clean these up as soon as we can find time. Best of luck. If you have any difficulty, don't hesitate to ask.

And, though I'm sure it's obvious, most of what you want is in the Microsoft.DirectX.Direct3D namespace. I haven't seen any simple standard Dx9 code that couldn't be written using managed Dx yet. Sometimes it's a pain in the arse (as the standard Dx way of doing things does not always have a direct equivalent in MDX). But even things like swap chains (which we found to be an interesting experience in Midget3D) can be done easily in MDX once you figure out how. You mentioned the "basic cube spinning example". If you haven't been there yet, have a look at http://www.directx4vb.com/. Jack's tutorial takes you right through building a cube-spinning demo. :)

To anyone interested in Managed Direct3D: The project I spoke of earlier this summer (http://www.xtremedotnettalk.com/showthread.php?s=&threadid=71998) is completed. You can find it at: http://www.midget3d.com/ The 4 of us working on it decided the pain we went through could save a few others from enduring the same, so Midget3D is entirely GPL'd. Feel free to hack up the code, use it to learn Swap Chain basics, or put it on your own site. Feel free to email me if you enjoy it, find undocumented bugs, or build on it and want your code published. Also, this is my first crack at Direct3D in many moons (can we say 1996?), so if you're a DX guru and think we REALLY messed something up, let me know so I can fix it. Ryan and I are going to continue working on it, so expect fixes for documented bugs sometime in the near future. :) Enjoy! .steve

Heh... The documentation on Managed Dx is downright painful. Most of it (if it exists) appears to be written by a summer student. :P I particularly enjoyed example code commented with phrases like "get rid of this crap" and "blow out of here". Good work with the QC there, MS.

Also of note: I'd be plenty happy if I could generate any other type of movie file: MPEG or MOV/QT would be fine by me. :) I know this is ridiculously easy to do with the Java Media Framework, but unfortunately, Sun managed to make these features of the JMF require a version of Java just a few notches higher than that which the current Java-to-.NET converter can do. Coincidence? ;)

Sorry 'bout that. They're fixed now. (Good ol' vBulletin decided it needed to add an extra URL tag, so those links had an end tag embedded in them.)