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!