Mike_R

I code only in VB.Net due to the fact that I work with MS Excel. The MS Office Apps all utilize VBA natively, and works pretty well with VB.Net. C# does work with MS Office, but the coding is pretty ugly. :( That said, I think it's well worth learning C#, at least being good enough to read it. I just find it advantageous to be able to read C# code then I see it being discussed. I also have some C# books and although I usually read VB.Net, some topics I'll switch to the C# book to get another perspective. My point is that adding some modest C# ability is a not a bad thing. If you want to persue this route, I would get a good intro C# book. I personally think that Jesse Liberty's "Programming C#" is just a fantastic book. I'd go with that. I would not drop any money on a C# IDE. You should probably check out #Develop or download MSFT's C# 2005 Beta. I don't have personal experience with #Develop, but it does have a good reputation, I believe. I use the C# 2005 Beta and find it excellent. Guys like you are me are not likely to flip over to C# completely. (Well, actually, I would really consider it, but my VBA use makes it kind of impossible for me.) If by reading a C# book over time and experimenting with the C# Beta (or #Develop's IDE) then, well, of course you may reach the day when you say, "wow, you know what, I think I prefer C#!". But that will take a while... I think it's easiest/best to master VB.Net and then switch over later, not earlier. But having a good C# book and a free C# IDE to be able to kick around some code can still a very good thing to have in the mean time... -- Mike

Ok, well it being ignored, though frustrating to he programmer, does make sense. Who are "we" to decide what the optimum arrangement is? We might have some idea of the inner workings, but only the compiler itself can best make these decisions. So I can see the sense in it being ignored. This has greater weight when one considers that the JIT'er is most definately going to evolve and improve over time... So for us to decide to Inline something today may make our <Inline()> Attribute meaningless or detrimental to the compiler tomorrow. I'm curious about how this works in C++ anyway. Forget for the moment that it's *ignored* -- lol, tough to ignore -- but ignoring that, in C++ is this a sort of "Attribute" attached to the Proc() itself, or is this a modification to the Call, effectively something like 'Call Proc() Inline'. It sounds like such *manual* Inline statements probably should not exist... but assuming one were to have them, I'm thinking that it makes more sense to tag the Call as "Inline" instead of tagging the Proc(), which would force it to always be Inline... But I don't know. I guess having both would give the most control. Anyway, how does it work in C++? Is the Proc() tagged as "Inline" or is the Call tagged?

LOL :) Funny thing is, this Attribute really makes the Control *almost* MustInherit, right? Sure, the Control could still be created programmatically, but this is not the most usual use for a Control. To use a control, most typically, it's going to be in the Toolbox... and so by adding this <ToolboxItem()> Attribute, the control *effectively* becomes "MustInherit", at least in terms of using the Control at Design Time... Neat, thanks for the heads-up. :cool: [Edit: You know, it's really weird, that the BaseClass shows up like this, eh? I wonder why.... This <ToolboxItem()> tag is a neat *fix*, but it's starting to feel more like a "patch". I wonder what's happening behind the scenes that causes this to occur... For example, if one uses Visual Inheritance of a Form, instantiating the DerivedClass Form does not simultaneously create an instance of a separate BaseClass Form as well! So this Toolbox Control "inheritance" really is sort of odd...]

Ok, this post is 2 mos. old now... So I'm guessing that you've very likely gotten this sorted by now.... But I would guess that you would not need the Professional Version. This is just based on my experience with VB.Net Standard vs. VB.Net Professional. Basically they are the same, it's just that the "Standard" version lacks things like a "Class Library" project and the like. Now you wish to make a DLL that can be called by VB.Net, so not having a "Class Library" would be annoying... but not that big of a deal. You can get around it in VB.Net easily by simply editing the .vbproj file and changing OutputType = "WinExe" to be OutputType = "Library". That's it. I would think that the adjustments for a C++ project would be similar? You might also try kicking around the Visual C++ 2005 Express Beta. Being 2.0, of course, it would have added features, but you could kick it around for free and it is "conceptually" the same as the stand-alone "Standard" versions. Anyway, something tells me you must have gotten this solved long, long ago... Hope this is of some help anyway... :), Mike

Huh, very cool! :cool: Much better than what I was thinking... But I wonder if making the Base Control 'Abstract' ("MustInherit") would have also worked? That attribute is very slick though, no reason to even try my silly idea...

Yes, the 'FormDLL1' is the name I gave the Class within the 'vbBlankClassLibrary.dll'. I'm not quite sure what you mean by "inheritance Picker"? I guess you mean Alt|Project|AddReference...? The reason it shows up as 'vbBlankClassLibrary.dll' is because this is what I named the Class Library (the DLL). Look in the Solution Explorer, you'll see the 'WindowsApplication1', which is the Startup Project (the EXE) and you'll also see 'vbBlankClassLibrary' which is the Class Library (or DLL) Project. The 'FormDLL1' is the name I gave to the Class/Form that resides within the 'vbBlankClassLibrary'. Ok, maybe say the "Inheritance Picker" you mean the "Object Browser"? Anyway, you just stated that it read: and then state "I was looking for "FormDLL1" and it wasn't there.". It sounds like it was there, no? The Form1 will be available within the Project (Namespace) it originates. In this case it will be available within the 'WindowsApplication1' only. I don't know. Forms/Classes are inheritable by default. Are you sure you want to be Inheriting Forms though? Visual Inheritance is supported in VB.Net, but are you sure you want to be doing that? Do you want to be able to Call the Form that resides within your DLL, or do you wish to Inherit from it? It sounds to me that you must have burned through your books a bit too quickly. You might want to go back to the VB.Net book that you like the most and re-read the chapters on Classes, Objects, Inheritance and Forms. It feels to me that you are doing ok, actually, it just sort of feels like your shoe laces were untied and you got yourself all tangled up... Take it slow and I think you'll work through this. Once you have the basics down of how to start a Project and Add References, etc., I think you'll be ok... -- Mike

The following relates to this post here: Compile Form to DLL Post #24. The details of that are not important, but I was knocking up a quick form for Realolman, and used the some code within Form1 to create a New Form2. The code looks straight-forward (and it seems to work fine), but there's something odd about it... I'm going to translate the code to C# here. I just wanted to be certain that VB was not doing some sort of "special hand-holding" behind the scenes. I didn't think that it was (and the following proves that it wasn't), but I just wanted to be certain. Here's the scenario: There are two Form Classes, called 'class Form1' and 'class Form2'. The 'Form2' class has no code in it at all. The 'Form1' class has only one Button Control ('button1') and when clicked it creates and shows a New Form2 class. Simple, right? Here is all the code within Form1: namespace csFormLifetimeTester { class Form1 : Form { public Form1() { InitializeComponent(); } private void Form1_Load(object sender, EventArgs e) { } private void button1_Click(object sender, EventArgs e) { Form2 frm2 = new Form2(); frm2.Show(); } } } And it runs fine... Every time you click the 'button1' you get a new 'Form2'. Perfect. Or is it? What bothered me is that I was sloppy and had the button1_Click() event procedure holding its 'Form2' reference locally in the 'frm2' variable. Then the call to frm2.Show() is modeless and so the code runs out and frm2 is set = null... So I was thinking "wow, this is dangerous... at the next GC.Collect() call, all these Form2's -- which look alive -- will be collected! The User is in for quite a shock!" And the Programmer (me!) has fallen into an easy trap, as the incorrectness of this approach is not evident when you run it... In fact, if the Application is small and does not use the Heap much, GC.Collect() may never occur and there may never be a problem with this. So just to make sure my thinking on this was correct, I changed the button1_Click() event to the following: private void button1_Click(object sender, EventArgs e) { Form2 frm2 = new Form2(); frm2.Show(); frm2 = null; GC.Collect(); GC.WaitForPendingFinalizers(); } We set frm2 = null and then force the Heap to be collected... And guess what? The Form2 still persists, as if absolutely nothing has happened. Wow. In fact, you can keep hitting the 'button1' and create multiple instances of this 'Form2' class, like in in the "Sorcerer's Apprentice". But what the heck is keeping all these instances alive? So I'm left with two theories as to how this might be occurring: (1) I suppose that my best guess is that the Form has some sort of code running in a loop at all times in the background. As long as it's running, it is "alive". The loop, I guess, is simply "event listening" but it is either implicitly keeping itself alive, or possibly even explicitly doing so by making a continuous call to GC.KeepAlive(this) in a loop, or, well, really it just needs the GC.KeepAlive() call in the line just after the loop exits... Obviously a call to Form Close or really .Dispose() ends this process and allows the form to "die". (2) There could be a "master set" of Form references in the background??? This feels very VB6-ish though -- the old "Forms Collection" that is secretly holding a reference to everything in the background. Sounds very ugly, and I know that VB.Net it working on such stuff for v2.0 (and my-god, I really hope they re-consider this. :(). I actually expect that this is not the reason... well I certainly hope not! Anyway, I have yet to read my .Net book's chapter on "Forms & Controls", so maybe this is all spelled out right there... But I was wondering what other people's thoughts were on this or if anyone definitively knew what is going on behind the scenes to keep a form "alive"? -- Mike (See attached if anyone feels like kicking this around...) csFormLifetimeTest.zip

Ok... no trouble, just glad it's working so far. :) Now I just added a new Form by right-clicking on the 'vbBlankClassLibrary' in the Solution Explorer window, then choosing 'Add' and then 'Add Windows Form' and then choosing 'Windows Form'. I then renamed the name of the Class to be "FormDLL1". I then added some code, which is not that important. It's just some basic starter code with one TextBox and one Label. How we call this form is what is important. We now shift over to the 'Form1' within 'WindowsApplication1' and add place the following code: Public Class Form1 Inherits System.Windows.Forms.Form Private Sub Button1_Click(ByVal sender As System.Object, _ ByVal e As System.EventArgs) _ Handles Button1.Click Dim dllForm1 As New vbBlankClassLibrary.FormDLL1 dllForm1.Show() End Sub End Class This is all we need. When you click 'Button1' on the 'WindowsApplication1.Form1' the Sub Button1_Click() gets called. The code within that does the following: Dim's a new 'dllForm1' variable and sets it to a New 'vbBlankClassLibrary.FormDLL1'. Calls dllForm1.Show()That's enough to get you going, try it! (And yes, the new version is attached below. :)) (Note that to open a Form in "Modal" mode, instead of "Modeless" as the above does, you would instead call 'DllForm1.ShowDialog()', which also returns a result showing how the Form was closed). You're probably close to being out of the woods I think at this point... However, as you are seeing first hand, .Net is not a "jump right in" environment as was VB6. I think it's really important that you pick up a good .Net book. For a general listing, you can see this Forum's listing of Samples, Books, and Tutorials. However in your case, you really could use a good VB.Net book in particular, so you should probably have a look at XDNT's listing: Visual Basic .Net Books. But don't hesitate to re-post here! I don't mind at all walking you through this.... But you should try to understand how the current version is working. If you don't quite "get it" then just ask! :), Mike vbBlankClassLibrary.zip

Ok, we can get you going, taking it to the next step is not hard at all... However, before going forward with how to make a Form, etc., we need to know if the existing Project is running as intended. If not, then we may need to change some settings, or references, etc... So please confirm this first: If you download the latest attachment (in post #16) and then (1) Open the 'vbBlankClassLibrary.sln' and then (2) Hit the 'Start' button (or the <F5> Key), do you get a MessageBox that reports "vbBlankClassLibrary.Class1"? If you got that going, then we can take it to the next level, which is not hard at all. So confirm at least that it's running right as is... If not, tell us what happens, or what error message you get. :), Mike

Huh, well this looks related as well, also from TheCodeProject: http://www.codeproject.com/vb/net/DotNetCompilerArticle.asp I really don't have any experience with Reflection, but this does look intriguing...

Ah, ok, that's great information to know. :) Yeah, I'm not real worried, I doubt that I could even detect a difference... But if there were such an attribute, I can see why it could be useful. Funny that the compilers choose to ignore it anyway, but I can understand that as well... I'm going to break up the code, but when I'm done, for kicks, I'll try a Copy-Paste version and time-test the difference. Something tells me that I won't be able to detect one... I'll report back if I find otherwise. Thanks Plausibly, I really appreciate the feedback...

Heh, ok, thanks :) As for your current issue... Well, you can't run a DLL directly, right? If you want this to run directly, you should really make an EXE! I guess you got the following error message? What you need to do is add another Project that acts as the EXE calling your DLL: (1) Within the Solution Explorer, right-click on the very top entry: "Solution 'vbBlankClassLibrary' (1 project)". Choose "Add" and then "New Project..." (2) This Startup Project needs to be an EXE, so choose a "Windows Application" project. Give it an appropriate Name and Path Location and then click <OK>. (3) If you didn't rename it from the default, the added project will now be seen within the Solution Explorer under the name "WindowsApplication1". We need to do two things with this new Project: (a) Right click on the "WindowsApplication" Icon and choose "Set As Startup Project". (This is roughly in the middle of a rather long list of choices.) If you did this correctly, then your 'vbBlankClassLibrary' will no longer be in bold and 'WindowsApplication1' will now be the startup project and will show up is bold. (b) We need to add a reference to your 'WindowsApplication1' Project to your 'vbBlankClassLibrary'. Under 'WindowsApplication1', right click on 'References'. Choose "Add Reference...". Then click on the 'Projects' tab and you will see your 'vbBlankClassLibrary' there. :) Double-click it and then click <OK>. At this point you can now add code within your WindowsApplication1, referring to your DLL. In other words, you can now add code like: Dim oClass1 As vbBlankClassLibrary.Class1 = New vbBlankClassLibrary.Class1 MessageBox.Show(oClass1.ToString) ' <-- Returns "vbBlankClassLibrary.Class1"Hope this makes sense! Mike (Again, see attached project... :)) vbBlankClassLibrary.zip

I guess this does not exist, but I'm hoping that there are some Attributes that can help direct how a Procedure is Optimized by the IL Assembler and/or JIT'er? Here's the basic scenario, let's assume we have a double loop, something like this: static void Proc1() { for (int i = 0; i < 100; i++) { for (int j = 0; j < 100; i++) { // Your Code Here // Your Code Here // Your Code Here } } } However, I expect to actually utilize the inner-loop in a couple of different ways called in slightly different contexts. So I'm inclined to break it up as follows: static void Proc1() { for (int i = 0; i < 100; i++) { SubProc(); } } static void SubProc() { for (int j = 0; j < 100; i++) { // Your Code Here // Your Code Here // Your Code Here } } As for my coding, this 2nd variation would be better. The issue I have with this is that I need this to run fast. I realize that the extra stack-frame creation is rather small overhead... And the Compiler/Optimizer might actually Inline this for me anyway, so why worry? (It's a rather small/tight routine that I think would have a pretty good probability of being Optimized/Inlined.) I was just wondering if there was an Attribute that could direct the Compiler to "Always Inline This Procedure"? I can force this myself with Copy-Paste, of course, but I'd really rather avoid the code replication in multiple locations. I guess that a C-Style Macro Expansion would be another route for this? Does C# support that? However, I don't really love the "Macro-Expansion" concept; it just feels a little sloppy... And I'm using VB.Net anyway, so I'm sure that VB.Net can't do this. I think the cleanest solution, really, would be an "Inline Attribute" if such a thing existed... Any thoughts? -- Mike

No problem! Just glad it worked... :cool: (I was starting to worry!) Have a great day :), Mike

Oh, I'm sorry... (1) Ignore the "security warning" in this case. It just means that this project did not originate on your own PC. (Which you knew. :)) (2) Yes, a DLL "Class Library" does not include Forms support by default. It can be added however. (Sorry I forgot to add this in the original attachment.) You can add it by going to Alt|Project|References... and then clicking on the '.NET' Tab. Then scroll down until you find "System.Windows.Forms.dll". Select it and then click <OK>. After that, you should be able to add Forms and Controls no problem. :) (3) Or use the new-project that I've now attached below, where I've added that Reference for you. -- Mike vbBlankClassLibrary.zip

No problem... All you need to do is click on the 'vbBlankClassLibrary.sln' file. That will get you going. :) (You could also double click on the 'vbBlankClassLibrary.vbproj' file within the vbBlankClassLibrary folder.) After that, add your code, and then hit 'Build'. (You can Build in Debug or Release Modes.) After that you will now have a DLL file at "..\vbBlankClassLibrary\bin\vbBlankClassLibrary.dll". At that point you could make a new EXE Project (which your Standard Edition can produce natively) and choose Alt|Project|References... and then hit the <Browse> button and browse until you find your file at "..\vbBlankClassLibrary\bin\vbBlankClassLibrary.dll". From that point on, you can then reference your vbBlankClassLibrary.Class1, etc. from within your EXE. :) I hope this was clear? -- Mike

Ok, see if the attached will work for you...vbBlankClassLibrary.zip

You tried it manually using a Notepad.exe or Derek's templates? Assuming you used the Notepad, I don't know... I've done this before and it has worked fine. Is this for VB.Net or C#? Let me know which one and I can attach a sample, blank DLL project here that you can use. :)

Hey Nerseus, yes, Marble_Eater's right... Posts #4-8 all flow from the statement made in Post #3. Hey Mookie, sorry about the slight hijack... you did raise some interesting issues though! In short, you were wondering about Post #3 because it really isn't supposed to be possible like that. The Decompiler likely wrote "Implements" instead of "Inherits" there... a slight error. Care to tell us what you are decompiling/looking at?

Yeah, I think you caught me :( I think there were two holes actually... After posting this, I started thinking about what it would mean for an Interface to "Implement" another Interface. It's pretty meaningless if you think about it... Say, if IFace2 could "Implement" IFace1, then Class1 could Implement IFace2 and get them both ("two for the price of one") but this pretty silly, as Class1 could Implement each individually anyway. (In other words, would one have to Cast twice to get from Class1 to IFace2 and then to IFace1?? No, clearly you can do it in one shot, but that's Inheritance, not Implements...) The 2nd "hole" was my misunderstanding of C# syntax, as I don't use C# very much. Well, pretty much never. So I had thought that when I see a Class declared as follows: Class Class2: Class1, IFace2 { } that this meant that Class2 Inherits from Class1 and Implements IFace2. But I incorrectly assumed that this "same" concept applied to Interfaces... But since Interfaces "Implementing" each other does not make a whole heck of a lot of sense, it does make sense that the syntax has a different meaning here. Thank you for helping me get my head on straight... That "Kosher" Example is very good. :) So it looks like you and Diesel were right: a mistake in the decompiler, eh? Still, have a look at this Inheritance of the Object Class issue with C# vs. VB, it's pretty interesting: Strange Interface Behaviour in VB.Net vs. C# -- Mike

Ok, kicking this around a bit, it looks like you're right about VB: VB.Net Interfaces can Inherit, but not Implement. But it does look like C# Interfaces can Inherit and implement. This seems to be legal: interface IFace1 { } interface IFace2 { } interface IFace3 : IFace1, IFace2 { } The equivalent in VB.Net is not: Interface IFace1 End Interface Interface IFace2 End Interface Interface IFace3 Inherits IFace1 Implements IFace2 ' <-- ** No good ** End Interface It chokes on the Implements keword. Odd, right..? Now there's something else interesting that I stumbled onto on the Web: it seems that VB.Net Interfaces are truly *pure* Interfaces only, while C# Interfaces, although technically incapable of Inheriting from other Classes, they seem to implicitly Inherit from the Object Class. VB.Net Interfaces do not even inherit even from this: Strange Interface Behaviour in VB.Net vs. C# Crazy stuff...

My guess is that you have reverse-compiled something originally written in C#. I'm not very experienced with C#, but I believe that a C# Interface can Implement another, or at least Inherit... but in VB.Net, this would not be permitted. (I'm sure the C# guys will jump all over me if I got this wrong! Feel free... :)) So your code, when reverse-compiled, is not technically legal as VB.Net code. The compiler would not permit it.