rbulph

As a related matter, I notice that .net allows a dll to reference an exe. In VB6 this was not allowed, you had to remove everything that you wanted to expose from the exe into a dll, to be referenced by both the exe and any additional dlls. So, if you were catering for plug-ins, you would have an exe, a dll with interfaces and your object model (the "class library"), and any number of dll plug-ins. As a matter of project design, would it now be reasonable for me to do away with the class library, put everything currently in there into the exe and have the plug-ins reference the exe rather than any class-library? It would do away with quite a lot of events that the class library has to raise. But perhaps a plug-in writer expects to refer to a class-library rather than an exe?

I think Internal is a JScript keyword - certainly it doesn't seem to be recognised in VB. I'm not sure what a wrapper class is or how it would help. As for immutable classes, there's an ImmutableObjectAttribute that you can apply in VB to a class, but I think it stops the object's properties from showing in a property grid, so that would be no good for me. So as far as I can see, my route of having a flag to record whether an external procedure has been called, and checking the value of that in all Property Sets is still the best way.

I'm not sure this would work, would it? I don't know what MD5 is, and maybe what I'm doing below is not the same as your suggestion, but it gives me the same value both before and after changing the property of the object. Public Class Form1 Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load Dim M As New abc Debug.Print(M.GetHashCode) 'returns 39086322 M.name = "H" Debug.Print(M.GetHashCode) 'returns 39086322 End Sub End Class <Serializable()> Public Class abc Public name As String End Class

An idea, certainly. Another idea I had was based on the fact that all of the objects I expose have custom type converters attributes and each property has a custom property descriptor. I thought perhaps I could override the SetValue method of the custom property descriptor class to only set the value when a certain flag was set to indicate that the code was running within the application. But it seems that the SetValue method is only called when the property is changed through a property grid, so that was no good. I think the best thing may be to just have a flag that I check in every Property Set method. It's not actually that much trouble.

Thanks. Yes, you can have properties with different accessors for the Set and Get in VB8. I wasn't aware of that. But (why does there always have to be a but?) the property grid seems to act as if it is external to the assembly which it's displayed in, i.e. it shows properties declared as you suggest disabled. And I do need to use the property grid. This is the code I have: Public Class Form1 Dim f As New Class1 Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load f.Prop = 6 'no problem Me.PropertyGrid1.SelectedObject = f ' "Prop" is disabled in the grid! End Sub End Class Public Class Class1 Private pd As Long = 5 Public Property Prop() As Long Get Return pd End Get Friend Set(ByVal value As Long) pd = value End Set End Property End Class Hmm.

If you expose an object to a plug-in you are opening yourself up to the possibility that the plug-in might change properties of the object. This is because the object will be passed ByRef even if the procedure that the plug-in implements declares the object parameter as ByVal (try it if you don't believe me). So is there a way to effectively make all the properties of an object read-only to certain dlls? I suppose you could do this by having a flag to be set when the object is passed out to a plug-in, and checking for the state of this flag in every Property Set in your object. But it's a bit tedious. Is there a better way?

Yeah, I understand interfaces, but I think I prefer to do this with an overriden procedure in the base class, since I already have this structure, so as to avoid having to create a new interface.

They do all inherit from a single base class. The reference I have is to a base class object and then I'm performing the check to see what type of inheriting object it is. But I see what you mean - I could give the base class a procedure and override it in each of the inheriting classes to do whatever I'm currently doing for that class in my type checking routine. Then just call that procedure instead of checking the type. Yes, I suppose that's a good point. It would be better encapsulation.

I have an object and I want to do different things depending on what type it is. Rather than say "If TypeOf x is class 1, elseif TypeOf x is class2 etc.", it would be good if it could say "Select Case x.GetType, Case GetType(Class1), Case GetType(Class2) etc.". That's all. It's not a big issue at all.

Not sure that some of you have undestood what I was originally asking. I'm well aware that you can use a series like "If, ElseIf, ElseIf...End If", but if the reference for the object you want to check is quite lengthy (e.g you need to go down a long chain of properties to get to it) then you have to either declare a new variable to refer to it before you call the conditions, or keep getting the reference to it in each condition. I suppose the former is OK, but I was after a way to use Select Case, as this would be easiest to read. I've since found that you can in fact use a Select Case structure for your own objects provided you define an = and a <> operator for them as follows: Public Class Form1 Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load Dim g As New abc Dim h As New abc Dim p As abc = h Select Case p Case g Text = "p is g" Case h Text = "p is h" End Select End Sub End Class Public Class abc Public Shared Operator =(ByVal a As abc, ByVal b As abc) As Boolean Return a Is b End Operator Public Shared Operator <>(ByVal a As abc, ByVal b As abc) As Boolean Return Not (a = b) End Operator End Class

Here's the answer, if you're interested http://forums.microsoft.com/MSDN/showpost.aspx?postid=790038&siteid=1

The sad thing is, there are some people who really do carry on like that.

I have a project with a class library, both open in the IDE. Why do I find that errors in the class library do not cause the debugger to stop execution at the relevant line, but instead to go right the way up the call stack back to the project, and exit the orginal procedure? This naturally makes it hard to track down where an error is occurring. I have tried recreating this with a simple project, but I do not get the same problems there. In both the simple project and the one I am developing the Debug tab of the Project properties has "Enable the Visual Studio Hosting Process" checked, so there is no difference with that that might be causing it.

Thanks, I agree that marble_eater's approach is preferable. In either case it's all a bit counterintuitive because you're never using the classes to create objects, you're using them more like namespaces, but it works so that's the important thing.

Ah yes, that does it, thanks. Contrary to appearances I do use my fingers to select the names - and I find I can do this remarkably quickly. I've also found in earlier professional experience that people who produce absolute rubbish can do it very quickly and it can be hard to criticise because nobody knows what on earth they really intended and it's far too rude to say that it's rubbish. If you're more conscientious then you have to worry about a host of details such as "'i' before 'e' except after 'c'" (!), otherwise it shows. So I use the random technique of name selection (sometimes).

You can't use Static like that in VB.net. You can only use it for variables within a procedure that you want to have retain their value across calls to that procedure.

If you add a Word file as a Resource to a project, how do you then open that file from within your code? Not like this, at least: Public Class Form1 Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click Dim p As New Word.Application p.Visible = True p.Documents.Add(My.Resources._2002_AGM_Minutes) End Sub End Class I can't figure it out. It was so easy in VB6 with an OLE container. Grateful if someone can tell me.

Oh yes, of course. However it would still be useful if I could do as I was originally anticipating for the case where the procedure wants to take two string arrays, for example. You can't have two ParamArrays as parameters, because there's no way of specifying where one array ends and the next begins.

Is there any way that you can create an array to pass directly as a parameter? i.e. avoiding the need for the variable f in the following code and just putting the array elements in the call to the procedure: Public Class Form1 Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load Dim f() As String = {"ioj", "OIJ"} hioh(f) End Sub Private Sub hioh(ByVal f() As String) End Sub End Class It seems to me that there ought to be, but I can't figure out what it is.

I see, thanks.

Where can you put initialisation code for a class library? I've got a List of objects which I use in the class library and I want to initialise it with data. Where would I call this from?

I don't think VB has that. I would have said that implementation in VB is all implicit, contrary to what you said in your first reply, because there is no need to cast the object to the interface in order to access the implementing methods.

Sometimes I may not know what type of objects I have except that they implement INameObject. But I suppose I can always do: Dim t1 As Type = CType(p, Object).GetType Dim t2 As Type = CType(c, Object).GetType Debug.Print(t1 Is t2) What's the difference between explicit and implicit implementation of an interface?