divil

Ah, in that case I misunderstood. I don't know how to do what you ask.

What do you mean a "browser help object"? I'm not familiar with the term. If you want to show HTML help from your app you can do so with the Help class and the HelpProvider class for context-sensitive.

I remember the previous thread. If I recall, the problem was (and still will be) writing that data out to file so that realplayer can play it. Your problem really lies with realplayer, and what it can support playing.

I don't think there are Property Pages as such - .NET offers far better support with the integrated property grid. You can make a property which brings up a modal configuration dialog when clicked using the UITypeEditor class, or you can add a designer verb which invokes a similar dialog.

That article is a little dated now. This is a common request and there is no control in the framework which can emulate the outlook bar. I wrote a control that does it well (not the one in that tutorial - although it works, it's far from comprehensive). It's available on my website for free. There are others out there too. http://www.divil.co.uk/net/controls/outlookbar/

What are Designers? Designers are the gateway between your user control and the developer at design time. Any control present on the design surface is fully compiled and sitting on a form just like it would be at runtime, only it has a designer applied to it. How do they Work? Designers subclass controls and only allow certain messages to get through. When you click on a button on a form at design time, for example, the button never receives the click message. Instead, the designer processes the message and the control is selected, just as you would expect. There are a few kinds of designer that you may come across, but they all implement the IDesigner interface. This fairly simplistic interface defines only four members, but in reality when you implement a designer you will inherit from either ComponentDesigner or ControlDesigner. What can I do with a Designer? Some pretty cool stuff. If you enjoy writing controls as I do, designers are a godsend. I'm not exaggerating when I say that more than half the time spent developing a control for .net can be spent developing the design-time experience. In most cases you can get away without writing one at all, but having a designer for your control or component helps give it that professional polish that people expect from good controls. An example of good designer usage is the .net Tab Control. This familiar control uses a set of tabs to switch between several client areas, thus saving space on forms where a lot of information is needed. The TabControl itself has a designer, which allows the user to switch the visible tab at design time. Normally click messages wouldn't get through to the underlying control at design time, but with the aid of a designer this is possible. The TabControl class adds TabPage instances to itself to host child controls. A TabPage doesn't do a lot more than inherit from ContainerControl so you can host controls on it. Or does it? In actual fact, the TabPage Designer class does more. For instance, it stops the user from being able to move the TabPage. It should stay stationary and be moved and sized by its parent TabControl, and the designer enforces that. Also, the designer listens for when the user selects the TabPage and deletes it, and notifies the parent TabControl so it can update its collection and interface. Another example of designer usage is the TextBox control. Have you ever wondered how it stops the user from resizing it when its multiline property is set to False? Well, you probably haven't, but it's with a designer, and it's remarkably easy to achieve. All the selecting, moving and resizing of controls you do at design time is handled by the designers that are part of the framework. Together with a bucket load of interfaces implemented by the host environment, you can create an extremely flexible and intuitive design time experience for a developer using one of your controls. Writing a Designer As this article is only meant to be a brief introduction to designers, we won't make anything terribly complicated. Before we can make a designer we need a control to design, so we'll create a simple usercontrol that draws an ellipse in its client area. To create a custom designer for a control you will either inherit from ControlDesigner or ParentControlDesigner, depending on whether you want users to be able to place child controls in your control. All we need for this article is to inherit from ControlDesigner. You will need to add an assembly reference to System.Design.dll to see these classes. To associate your designer class with your control, you use the DesignerAttribute class: Imports System.Windows.Forms.Design Imports System.ComponentModel <Designer(GetType(MyControlDesigner))> _ Public Class UserControl1 Inherits System.Windows.Forms.UserControl Public Sub New() MyBase.New() SetStyle(ControlStyles.ResizeRedraw, True) SetStyle(ControlStyles.AllPaintingInWmPaint, True) SetStyle(ControlStyles.DoubleBuffer, True) End Sub Private Sub UserControl1_Paint(ByVal sender As Object, _ ByVal e As System.Windows.Forms.PaintEventArgs) Handles MyBase.Paint e.Graphics.DrawEllipse(Pens.Red, ClientRectangle) End Sub End Class Friend Class MyControlDesigner Inherits ControlDesigner End Class using System; using System.Collections; using System.ComponentModel; using System.Drawing; using System.Data; using System.Windows.Forms; namespace CSharpTest { [Designer(typeof(MyControlDesigner))] public class UserControl1 : System.Windows.Forms.UserControl { public UserControl1() { SetStyle(ControlStyles.ResizeRedraw, true); SetStyle(ControlStyles.AllPaintingInWmPaint, true); SetStyle(ControlStyles.DoubleBuffer, true); this.Paint += new PaintEventHandler(UserControl1_Paint); } private void UserControl1_Paint(object sender, PaintEventArgs e) { e.Graphics.DrawEllipse(Pens.Red, ClientRectangle); } } internal class MyControlDesigner : System.Windows.Forms.Design.ControlDesigner { } } In the Form designer, you should see the usercontrol you just created in the toolbox, and you can drag it on to the form like you would any other control. Although our designer class doesn't do anything yet, the instance on the form is using it. Now let's try preventing the user from resizing the control vertically, like the TextBox does. To do this you need to override the SelectionRules property of the ControlDesigner class, and return all flags for sizing and moving except the Top and Bottom ones: Friend Class MyControlDesigner Inherits ControlDesigner Public Overrides ReadOnly Property SelectionRules() As System.Windows.Forms.Design.SelectionRules Get Return SelectionRules.LeftSizeable Or SelectionRules.RightSizeable Or _ SelectionRules.Moveable Or SelectionRules.Visible End Get End Property End Class public override System.Windows.Forms.Design.SelectionRules SelectionRules { get { return System.Windows.Forms.Design.SelectionRules.LeftSizeable | System.Windows.Forms.Design.SelectionRules.RightSizeable | System.Windows.Forms.Design.SelectionRules.Visible | System.Windows.Forms.Design.SelectionRules.Moveable; } } Now, if you create an instance of your control on the form, you'll notice that the designer has disabled all sizing grips that would allow you to size it vertically. Next, we'll expand our designer to illustrate another cool feature; choosing what controls our control can be parented to. We will make it so that our control cannot be parented to Panel controls, but everything else will be ok. This may seem like a fruitless exercise, but it demonstrates a technique not uncommon when writing designers. All we have to do is override the CanBeParentedTo function and see if the potential parent designer is hosting a control of type Panel: Public Overrides Function CanBeParentedTo(ByVal parentDesigner As System.ComponentModel.Design.IDesigner) _ As Boolean If TypeOf parentDesigner.Component Is Panel Then Return False Else Return True End If End Function public override bool CanBeParentedTo(System.ComponentModel.Design.IDesigner parentDesigner) { if (parentDesigner.Component is Panel) return false; else return true; } You will now find that your control can be dragged in to most parent controls, like the GroupBox for example, but not Panel controls. The last thing I will cover in this article is designer verbs. These are actions that are presented on the control's context menu and also as hyperlinks in the property grid when your component is selected, and allow you to provide an interface for the user for performing common tasks with your control. To implement designer verbs, you must override the Verbs property and return a DesignerVerbCollection object. Each designer verb is presented as a menu option and as a hyperlink in the property grid, and is associated with an event handler that is called when it is selected. Let's try adding one that simply shows a message box when chosen. Imports System.ComponentModel.Design Public Overrides ReadOnly Property Verbs() As System.ComponentModel.Design.DesignerVerbCollection Get Dim v As New DesignerVerbCollection() v.Add(New DesignerVerb("Sample Verb", AddressOf SampleVerbHandler)) Return v End Get End Property Private Sub SampleVerbHandler(ByVal sender As Object, ByVal e As System.EventArgs) MessageBox.Show("You clicked the test designer verb!") End Sub using System.ComponentModel.Design; public override System.ComponentModel.Design.DesignerVerbCollection Verbs { get { DesignerVerbCollection v = new DesignerVerbCollection(); v.Add(new DesignerVerb("Sample Verb", new EventHandler(SampleVerbHandler))); return v; } } private void SampleVerbHandler(object sender, System.EventArgs e) { MessageBox.Show("You clicked the test designer verb!"); } When your control is selected on the design surface, our hyperlink is now shown in the property grid. Conclusion Designers are a great way of adding that extra touch to any control, to make the developer's life that much easier when configuring it at design time. I'm aware I've only scratched the surface in this article, but I intend to go much deeper in future tutorials. I hope I've shown you enough to get you started writing your own designers. Consult the documentation for the other overridable members of the various designer classes, and don't be afraid to experiment! View Full Article with Downloads

System.IO.File.Copy, System.IO.File.Move You use Move to rename files.

Here's the zip file without a binary inside:jftp.zip

If you're storing key/value pairs, you could consider the Hashtable class. Any list class will likely be better than the Collection class which is only provided in VB for compatibility :)

You can't. The best you'll do is manually drawing the whole textbox, which would be a pain since textboxes look different on XP from previous versions. Why are you trying to do this?

Sometimes the garbage collector needs a little help, so if after you've removed a lot of items you make a call to GC.Collect() that might well help things along too.

What language is this ActiveX control written in?

Use the .Filename property of the SaveFileDialog.

If you're referring to the tabbed dialog control, you can set the background colour of the client area of the pages but not the tab "ears" themselves. Filesystem type is irrelevant, you don't need NTFS to install VS.NET.

If you are looking for Windows Forms Controls, you can find a good selection of libraries and articles at http://www.windowsforms.net .

That would probably be a red herring anyway, I don't think controls play nicely with each other if they're on different threads. What I was suggesting was to move your BuildIndex function in to an entirely different class. I assume if you were in the position to write it in .net (most preferable) you would have done so. So my thought was to make another public class in the same library as the ActiveX control, and stick the BuildIndex function on that. You could use internal properties if you need to share data between the two.

Thanks, I knew what you were trying to do. My personal feeling is that the ActiveX wrapper is automatically shifting to its owner thread (the UI thread) when you call methods on it. This makes sense to me, and I asked someone else who agreed. You might be able to create the ActiveX control on a new thread, that would probably fix the problem but I doubt it would want to be parented to your form in that case. Is splitting the intensive code off in to another COM class (i.e. not the ActiveX control) an option?

I don't know why that doesn't work, but if you want to change the cursor just do this: Cursor = Cursors.Cross

Could it be that a value type would be more suited for your needs, in this instance? That way when you pass them only a copy is passed.

Can you post an example project with instructions that demonstrates this?

I don't understand why the activex control raises an event when it's done - normally, that would imply that it was executing asynchronously. I would have thought your method would simply return when it was done. I don't know why calling that method in a new thread would still lock up your program, but I have heard that ActiveX controls (and any UI control for that matter) don't play nicely with threads. It may well be putting itself on the main UI thread and won't budge.

Calling the API _does_ work. I even posted an example project that does this here.

I said already, that the standard edition can't create dlls. You could always experiment with the command-line compiler.

Why would you inherit from ArrayList? If you need to make a collection of your own type, you should inherit from CollectionBase and provide your own accessor and add, remove functions etc.

Very useful tips Nerseus, I had no idea VS could do column selection :)