snarfblam

Public Sub Example() 'Get function pointer Dim myDelegate As EventHandler = AddressOf SomeForm.Button1_Click 'Pass it to a function MoreExample(myDelegate) End Sub Public Sub MoreExample(ByVal Handler As EventHandler) 'Accept function pointer and use it AddHandler Button1.Click, Handler End Sub

How are you printing? If there is a Graphics object involved, try using RotateTransform().

Try this tutorial. The code is in VB, but the concepts are applicable.

I don't think that easter eggs are anything to complain about. I don't think that they are a waste of time, effort, or resources. I think that they are merely an acknowlegement that the programmers and the users are still both humans, and there should be no reason why people can't smile now and then while using Excel or Visual Studio. That's just my opinion, but I think that it's nice to, now and then, have a reminder that real people work at Microsoft.

Have you tried domSetup2.PrivateBinPath = IO.Path.Combine(Application.StartupPath, "P1"); instead of domSetup2.PrivateBinPath = "P1";

I would not recommend trying to save the IDataObject from the clipboard in the first place. The object returned by the ClipBoard.GetDataObject is not the data itself, but an object that will get you that data (it may or may not store the data internally, I couldn't tell you). Without doing any research, I would guess that when the clipboard data is replaced, the behavior of the old IDataObject is not defined and becomes unpredictable.

You would probably have better like finding a DLL/ActiveX/.Net based MIDI library that you could use from C#.

I think that in general (at least, as far as the .Net framework is involved) a relative folder path should not start with a backslash.

What's wrong with my encryption/stream example?

Does the idea of a Windows command prompt replacement program pique anyone's interest? There are many desktop replacement programs and it seems that plenty of people like them. They don't do much for me because I don't really use the desktop. I would be a big fan of the Windows command prompt but it just seems crippled and obsolete. The syntax tends to be awkward and extensibility is minimal. If you want to add your own command you have an option between the batch file, which seems to be the clumsiest "programming language" there is, or write an entire executable to serve the purpose of that single command. Most importantly, it is just plain ugly. Hence, the need for a replacement. I have already begun to write a command prompt replacement, but I'm wondering just how much interest there would be, and if there is interest, would anyone has any suggestions or criticisms. The syntax is... unique... a mixture of different languages with the goal of being simple to write, simple to interpret, and concise. It has the added bonus of being able to create and manipulate .Net objects through the command line (in a manner similar to the Immediate window in Visual Studio). Commands are primarily function calls rather than shell commands, and functions would be provided to accomplish common shell commands. It could be docked as an appbar (like the task bar) so that it is always at your finger tips. This is a sample of what you might type into the prompt (this is all subject to change, though): [color=Green]/ This is a comment. / / Delete a file. You can use "escaped strings" and 'unescaped strings'. Exclamation marks identify functions. / [/color]!Del('C:\Windows\ThatFileImDeleting.txt'); [Color=Green]/ Change directory. There will probably be shortcuts for very common commands like this. /[/Color] !CD("System32"); [Color=Green]/ Get text from the user, and display the text in all caps. The assignment operator is a colon. /[/Color] $text: !GetLine(); $text: !ToUpper($text); !WriteLine($text); [Color=Green]/ Play with .Net objects. This adds a world of already existing functionality to the prompt. The carat identifies a handle (as it does in C++/CLI). The asterix is the instantiation operator. /[/Color] ^myForm: *System.Windows.Forms.Form(); ^myForm.Text: "Holy great goodness! A Form!"; ^myForm.ShowDialog(); [/Code]

I think that this is a bug with the TabControl Designer. I'm guessing that you are using .Net 2003 (I think that this is fixed in 2005, not sure). Try searching google for tabcontrol order bug. This topic has already been thoroughly discussed elsewhere.

Good point about the interfaces - how different objects behave over the same interface can vary. Passing certain objects to one ICollection can raise exceptions while passing the same objects to other ICollections will succeed. Common functionality, though, is the underlying concept. IEnumerators enumerate, ICollections expose a set of objects, IDisposable frees resources, etc. In an ideal world, every interface would have appropriate functions to allow us to use every instance that interface without making any assumptions. An ICollection interface would have a CanBeModified or CanBeAddedTo property, and an IsAcceptableObject function so that we would not have to worry about whether we are dealing with a TreeNodeCollection or a Byte array, but instead simply query whether a given object can be augmented with a collection. But we have to stop the abstraction somewhere.

You are right. It is shadowed in the RichTextBox and hidden from intellisense, and when you call Control.DrawToBitmap it only does the drawing handled by Windows: an empty rectangle with a 3D border. They didn't implement it. Either they ran into problems or didn't bother to try. I fiddled with some code, but no luck. What can I say, except tough luck. You can do a screen capture of the control and show that in a picture box (using the Graphics.CopyFromScreen function). That's the best I can do for you.

These things happen when you are multithreading. I am far from a multithreading guru, but here goes. To invoke certain methods across threads, especially when a GUI is involved, you can't invoke that function directly. It must be invoked on a particular thread, which means that you must call the Invoke function with a delegate. The Invoke function will invoke the function on the appropriate thread. It sounds like at some point .Net is just wrapping your delegates inside delegates with calls to Invoke to keep things from blowing up. The wrapped delegate will still end up invoking the same function, but it will happen in a more thread-safe manner. You might want to consider "unwrapping" your delegates. If the .Method property of either delegate is "Invoke", take the .Target, cast it to a System.Delegate, and check the .Method and .Target of that. You can compare these "unwrapped" delegates for equality.

You make a very important point, mskeel. It is something that never occured to me until recently; it is very difficult to understand why a tool exists until you have used it in a practical situation yourself. To that end, how about some examples of when you would each said feature. It might not be as education as certain books and tutorials, but for anyone who is merely interested in a quick read, here goes: 1. Overloading Nerseus gave an example of this. This is very nice any time you want to have a function, but there are different possiblilites of parameters that could be applicable. Instead of choosing one possible set of parameters, or writing a dozen different functions that do the same exact thing with different input, you make a dozen overloads for the same function. This is ideal for constructors, for example. Look at the System.Version class. When you create a System.Version object, you may want to pass a string (new Version("1.2")). You may want to pass integers (new Version(1, 2)). It might seem useless to be able to type "1.2" instead of 1, 2, but it is anything but useless when the data could either come from a textbox or a function that returns an integer. You may or may not want to specify revision and build. So you create overloads for each possibility. And, unlike normal functions, you don't have the option of creating a number of differently named constructors, so overloading makes life much, much easier. 2. Interfaces In programming we see the term "class" so often that we seem forget what it really means. A class defines a "class," or category, or type, of object. Stream defines a type of object. FileStream is a Stream. MemoryStream is a stream. They are all objects of the same "class" (or category, or type). A Bitmap is an Image and a Metafile is an Image. Interfaces define common functionality between objects that serve different purposes. Streams are a means of communicating data. Images are a means of representing visual data. But both of these different categories of objects have a certain common functionality: they both have a function to free unmanaged memory: Dispose(). This is the most common .Net Interface because it is a very commonly implemented functionality, but is not the fundamental function of the class. A TreeNode collection and an integer array are two very different things, and there is no reason why they should inherit the same base class, but they both represent some type of collection that can be enumerated, so they both implement IEnumerable. You can operate on an IEnumerable interface and not care about what class the object actually is. 3. Abstract Classes Abstract classes exist to define some, but not all, of a classes function. It is similar to an interface, but unlike an interface, it can implement some functionality. For example, the Control class handles keyboard and mouse input, but does not do any drawing. That is left up to the deriving class. The control class calls the OnPaint method when something needs to be drawn, but the Button class, or the CheckBox class, or whatever class, actually defines the OnPaint method. This can't be done with interfaces, and unlike regular inheritable classes, abstract classes don't have to implement everything. 4. Polymorphism Suppose you write a function to take data for input, encrypt it, and then output it in its original form. Suppose that you write this function to operate over an array of bytes. Then you want to use it for and array of integers. And then for a text file. And then for downloaded web content. And you end up writing four different functions. Suppose you wanted to be able to output in any of the four forms and output in any of the four forms. Now you need sixteen functions, or at least the very least four read functions, four write functions, and one encrpyt function. Now what if you write a function that accepts a stream as input, encrypts the data, and outputs the data to a stream. You can now use a MemoryStream object to encrypt a byte array, and a FileStream object to encrypt a file, and you don't need to write extra code to put the encrypted data in a different place from where it came. And then, if someone wants to encrypt data coming in through a serial port, they can write a SerialStream class. And not only can they encrypt the serail port data, but they can use that serial port data for any function that operates on streams. With polymorphism, you can write one function and that one function is incredibly flexible because it operates on polymorphic objects. Not only that, but you can expand what the function can do without any modification to the function by exercising polymorphism. Create your own stream class, and like magic, the EncryptStream function is capable of doing more.

System.Marshal allows access to the managed heap (and maybe other memory, not sure), but I would have to assume that it performs certain saftey checks to help ensure that what you do is legit (meaning it doesn't pose a threat to the managed environment or security). C# does have pointers but they are crippled. I am pretty sure that they are only allowed to point to value type objects on the managed heap, and exist mainly for the purpose of speeding things up when it comes to arrays of structs. As mskeel made a point of, .Net is designed to work in a "Managed Environment" which specificly does not require, and therefore intentionally restricts, potentially unsafe operations such as direct pointer access. In VB (and even C# for the most part) they lock pointers up and throw away the key. C++ on the other hand, is designed for exactly this kind of thing. If you really want to try this in VB, then consider the methods I recommended above. I don't even know if they will work, but I'm guessing that it would be your best bet if you don't want to get your hands too dirty.

Here is an alternative. In .Net 2.0, each control has a DrawToBitmap() method which renders the control offscreen to a System.Drawing.Bitmap. You can render the control to a Bitmap and display it in a PictureBox. It will look identical, but will provide no input functionality.

set_Item() is actually an accessor for the Item property. In VB and C# you can't directly access these accessor functions, but behind the scenes each property get/property set is compiled into a pair of accessor functions (if the property is "Item", the compiled function pair would be "get_Item" and "set_Item"). The ArrayList.Item property is actually an indexer (the default property in VB), which means that it can't even be accessed explicitly in C#, but code like this: ArrayList X = new ArrayList(); X[0] = "Text"; Object Y = X[0]; would compile into this: ArrayList X = new ArrayList(); X.set_Item(0, "Text"); Object Y = X.get_Item(0); I'm just guessing, but J# probably allows (if not requires) the get_/set_ syntax to be consistent with Java, which does not support properties (most Java programmers explicitly write get/set function pairs to attain the same functionality). So... myArray.set_Item(1, new Integer(4)) translates into myArray[1] = 4, which is not the same as myArray.Insert(1, 4) (although it may behave the same, I didn't check).

This is a very advanced topic, and I'm not too sure that you are going to find a satisfactory answer here. This is certainly not the type of thing that .Net is designed for. The most reasonable approach, I would think, is to create a DLL in C++ that can be consumed by VB if, for some reason, you need the front end of the application to be .Net. That being said, have you actually done this in C++? If so, what specific issue(s) have you run into trying to do this in VB? Obviously, VB does not have direct support for pointers, but pointer operations can generally be performed via the Windows API.

All you have to do is add a reference to the appropriate .dll and drop it in like a WinForms control. (On my computer the DLL was located at C:\Windows\System32\shdocvw.dll, the control is named WebBrowser). If this is the control you are using, what is the problem?

There is also an ActiveX web browser control you can use. I can't remember the details, but a google search should bring up plenty of info. And if you host an html file in a web browser control, it will behave exactly as it would in Internet Explorer (it is, in fact, an Internet Explorer browser minus the menu, title bar, status bar, et cetera).

Which version of C# are you using? C# 2.0 has a web browser control which can host html files, and while there is no way to simply run javascript code by itself (that I know of), as long as it is part of a web page displayed in a web browser control it will be run just as you would expect when browsing the page in IE.

Just a recommendation: if you are using a tabbed interface, you might want to consider hosting "child windows" in a user control rather than in actual forms to avoid any unwanted default MDI behavior. If you want an MDI/tabbed option, you can always host the user controls in forms docked to fill the form.