Mike_R

Sorry, it looks like I forgot a cast in the above. Try this when you get home:Dim xlWS As Excel.Worksheet = CType(xlApp.ActiveSheet, Excel.Worksheet) CType(xlWS.Columns("A:C"), Excel.Range).ColumnWidth = 20 -- Mike

No problem. :)

Plausibly, thanks for that advice. I'm a VB-guy and that ain't never gunna change. Even if I switch over to C#, which I may do when VS2k5 comes out, I don't see myself ever getting into direct-pointer operations. But it is neat to think about...

I'm sorry Tygur, I really confused the issue on that one... I was actually trying to support the arguement you just gave (that this is fine in VB), but I blew it when I got carried away with a caveat. I was replying to this: I was trying to say that this is fine in VB as well. I had thought that variable-procedure pairings of the same name were a no-no (but I guess I was wrong about that?), but as for variable-type pairings that's another matter and even VB can handle that fine. My example was:Sub MySub(textBox As TextBox) ' ... End Sub And my point is that this works. :) Your example takes it further, showing that it's fine. I've even used this myself, but I've started moving away from this as I sometimes get confused by the IntelliSense. What happens is that I type something like: TextBox. and expect to see IntelliSense listing only Static members, but instead I see Instance members as well and I'm all confused. What happened? Well, VB is not case sensitive, so even though I wrote "TextBox" and therefore was intending to access the Type TextBox (and therefore only see Static Members), I was actually getting a reference to the 'textBox' object (since 'textBox' is the more local, and therfore the shadowing definition) and was therefore given a listing of Static and Instance members. This is not a *huge* deal, but I find myself occussionally confused by this so I've started moving away from this... I now use "txtBox" instead: Sub MySub(txtBox As TextBox) -- Mike.

Yeah, I agree... this kind of thread is always at grave risk of going down in flames (litterally), but I think we're doing pretty ok. :)

Huh, ok, I had thought that this was a no-no, even in C#. So the use of the leading underscore ("_") for private variables is only a VB convention then? You know' date=' you can do that in VB6/VBA as well. But doing this in VB.Net it's a little more dicey. It is [i']legal[/i] to to this in VB.Net:Sub MySub(textBox As TextBox) ' ... End Sub But what happens is that the TextBox class definition then becomes unreachable because the 'textBox' variable definition is the local definition (and VB doesn't distinguish case). Mostly, it's fine, really, as the Static members are available on both the 'textBox' and on the 'TextBox', but the truth is, I started finding this a little confusing and have kind of stayed away from this in VB. Certainly less of a problem in C#, esp. if it is common usage and so people get used to looking for it.

Ok, Coldfusion, thank you for that description, I think I have a better feel (somewhat). On the Method Functions, I'm with you 100%. That makes sense. On Array's I don't quite fallow... Isn't any index in the Array of Int's found by: ArrayAddress + IntexPos*4? Is this math avoided when directly using Pointers? I don't quite see how things go faster... I've heard it described just as you did before, so I know you're right, it's just not sinking into my thick skull. As for Unsigned Types, it really does not seem to be that big of a deal, then. I never really thought that being able to use the high-bit as a positive value could really be that important... Thanks for the run-down... Dude, you drove right past my Appt! I'm in the Ravens Crest Appt's right next to Quail Ridge on Scott's Corner Rd. Next time you're in town, let me know, we could grab lunch or something... Ok, Tygur, that example you give regarding a case-sensitive name-conflict situation is excellent. Yes, you are right: VB could not do this. VB can name a Variable the same as a Type, but not when the Type is Nested at the same level like this. I'm not sure that this is great practice anyway, more standard would be to name a private variable with a leading underscore: public class MyClass { private class SomeThing { } private SomeThing _something; }

Oh, Mookie, I apologize for such an overwhelmingly long reply... I do not feel that these issues are all that relevant, honest. I would stick to what I advised in Post #3: That is, I would stick to VB.Net for now, but learning C# on the sideis really not a bad idea in my opinion. And, yes, you may eventually come to like C# more. :)

C# advantages: (1) Terse/concise language, (2) Use of Pointers in certain situations is useful. (3) The Ref/Out parameter enforced within both the Procedure and within the Caller is a very nice mechanism that I wish VB.Net had. (4) The Using Block is also nice (even if infrequently used) and is also unavailable in VB.Net. (5) Use of Unsigned Types, although, I don't really know why/where they are useful, myself, to be honest. However, Tygur, allowing C# (or any language) to be able to distinguish variable or procedure names by case is just an accident waiting to happen. Naming Convention guidelines always regard it as a huge no-no to name two variables, two procedures or a procedure-variable pairing the same, differing only by case. So why not simply enforce this at compile time? It's a nice error-catcher, believe me. I personally think that C# had a real opportunity here to break from C/C++ tradition and blew it. IntelliSense in the C# 2003 is badly hampered by this. For example, if you type "messagebox." you will get no IntelliSense. Nor for "Messagebox." You need to type the case exactly correct: "MessageBox." and then you'll get the drop-down. No hassles like this in VB.Net. (Note this is corrected in C# 2005.) The biggest advantage that VB.Net has is that the IDE is vastly superior in the 2003 version. I don't have experience with #Develop, so maybe it's different there, but I view the VS C# 2003 IDE as almost completely crippled. That said, this difference is narrowing substantially in the 2005 version. Many of the differences between C# and VB.Net are going away, but the biggest improvement for C# is the IDE. The C# 2005 IDE is almost as good as the VB.Net 2003 version. It's still "lags" a bit on keeping the Task Manager errors in synch, but it's almost right... I think they'll probably make sure that they get it to 100% at VB.Net's level before releasing it as a final version. VB.Net's advantages over C# are many, and I think that C# programmers would be shocked to know how much better some things are in "VB Land": (1) It's a non-case sensitive language, so spelling conflicts are resolved at compile-time. (2) Has a built in WithEvents/Handles mechanism that is significantly better than simple AddHandler. In short, it is a bi-directional mechanism, a hand-shake between the variable (or control) and the Event Handler. VB.Net also has AddHandler and Delegates, so it has everything C# has here, but for 95% of the time the WithEvents/Handles pairing is just much, much nicer. All events are available in the Drop-Down boxes, selecting one automatically creates the correct procedure stub for you. (3) Implementing Interfaces in VB.Net is a dream. Simply state 'Implements IMyInterface' and all your required stubs simply drop in automatically. It's hard to appreciate how easy and nice this is if you've never seen it. (4) C# lacks a With.. EndWith with block. This is a curious omission in my opinion. I guess this falls under the "not invented here syndrome", but I am pleased to see that C# guys are much more open to "outside ideas" than was the previous C/C++ community. There are a number of C# blogs and sites arguing for With.. EndWith. Given how easy this would be to do, I don't have a clue why it doesn't seem slated for 2005. I guess maybe the old-school C/C++ guys are in charge after all? (5) C# Lack a 'MyClass' Equivalent. In VB.Net, we have 'Me' (which is equivalent to 'this' in C#) and 'MyBase' (which is 'base' in C#). However, C# does not have an equivalent to 'MyClass', which is a sort of override-blocking mechanism. It can be achieved in C# by creating a core non-overridable procedure that is called by the overridable procedure and then calling the non-overridable one, but this is a hassle. 'MyClass' really does have a purpose, even if needed infrequently. You don't *have* to have this, of course, but lacking it is not an advantage. I find this one particularly odd, since this concept is not only supported by the CIL but actually has a direct representation. In short, a call to Me.SomeProcedure in IL is basically 'CallVirt SomeProcedure'. CallVert here means that if the 'SomeProcedure' is overridden then the overridden version would be called. A call to MyClass.SomeProcedure is the same, but ignores any overrides, should it exist. So how is this represented in the IL? Easy: use 'Call' instead of 'CallVert'. That is, instead of 'CallVert SomeMethod' it's just 'Call SomeMethod'. However, C# lacks this concept. (6) The Switch statement in C# is archaic looking to a VB-programmer. I suppose one could argue that it's more flexible, but the "flow-through" strategy and use of break or goto's looks like something from the stone ages. The Switch statement also cannot handle groups of values on one line (without resorting to flow-through and/or goto's). Try to do something like this in C#: Select Case i Case Is < 5 ' Do Something Case Is 10, 15, 20, Is > 25 ' Do Something Case Else ' Do Something End Select Use of multiple values or sets of evaluated values in one line can really clean up your code immensely. (7) C# lacks a project-wide 'Imports' ('using' in C#) statement. I'm a bit on the fence on this one. I guess overall, it makes things a lot easier. It does make particular documents a bit less portable though, because the Imports statement is not within the Document itself. A bit of a toss-up here, I'm not sure which is better. (8) C# cannot handle Properties that take a parameter. I guess this is open to debate (as is everything else I've listed!) but I think that C# is taking too strict an interpretation of "Property" here. I do "get" the mentality, I do: a Property is a surrogate for a Field, period. The Property may have some coding going on, but if you start adding Arguments, then it's a Function (er, Method), right? Well, personally I don't think it's so clear cut. Take a look at the following post: See Post #3 Here. In this situation, the coder had a simple Property: Overloads ReadOnly Property Weight() As Double ' Returns the Default value of Weight in Kilograms. Get Return Weight(WeightUnit.Kilograms) End Get End PropertyNow he wishes to extend it's capabilities to be able to report in Pounds, Grams or Kilograms. Does this suddenly become a "Method"? Is the 'Units As WeightUnit' parameter really making this into a function like one would consider Sum() or Max() to be a function? I would argue "no", it is still a property. I feel that a parameter that is merely aiding in determining the return format, or type, or units is not sufficient to no-longer consider this a property. But the point is that I can make this decision as a VB.Net coder. As a C# coder, this decision is made for me. (9) C# code is a bear to use if interacting with MS Office Applications. VB.Net code is more "legacy aware". I guess you could say that C# code is "legacy-aware", but it has a different legacy: C/C++. But for anything regarding MS Office, C# is very tough. Doable, but the coding is just very ugly. Much, much less terse than VB.Net code. This differential will go away eventually, whenever MSFT re-does the Office suite on .Net, but this will not go away at all with the Framework 2.0. Moving Office to .Net properly will be a long while in coming... (10) Related to this is that if one is using Late Binding then VB.Net is a dream compared to C#. To effect Late Binding in C#, one has to be a Master of Reflection. I suppose that the "Masters" out there would prefer to execute their own Reflection code directly, but for the 99% of the rest of us, using VB's Late Binding mechanisms and letting VB do all the Reflection for us in the background is uniquely valuable. I realize that this is a very long reply... My point (believe it or not) is not to try to prove that VB.Net is better than C#. But my point is that I think there is a heck of a lot going on in VB.Net that C# guys don't have a clue about, and would likely drool to have it if they knew what they were missing. The flip-side is, I'd love for someone to explain to me the *real* advantages to working with: (1) Unsigned Types (2) Pointer Operations I know that "for some algorithms" the use of direct pointers can be of real value. I would guess that this might occur if trying to implement a complex linked list implementation like a splay tree (or any sort of complex tree/trie or complex data structure)? But I'm just guessing... I don't really don't understand the big deal with Unsigned Types, I personally don't have a problem using Int64 if I don't have enough positive values within my Int32, but I guess using Unsigned might be helpful in certain bit operations? But let's step back for a minute and ask ourselves: why do C# programmers really love their language? I mean, come-on guys, what's the real reason? Answer: "It's the syntax, stupid". VB.Net "feels dumbed down", as Tygur put it. Other remarks along these lines I've heard include "VB code gives me gas." LOL :p There's nothing a VB.Net programmer can say to this. The truth is that VB is a less-symbolic language and so is much less concise. By using words instead of symbols, VB is easier for the beginner to read and so is more approachable by novice programmers. The result is that the C# guys see dumbed-down code, frequently being used by inexperienced programmers. The resulting bias on the part of C# programmers is understandable. But, Tygur, syntax aside, to take the next step and conclude that VB.Net itself is somehow "crippled" really could not be farther from the truth. -- Mike

Nice. :) I can't wait until 2005 is finally a full-release...

Yes. Believe it or not' date=' this is exactly how it works in VB6 as well. The difference is that VB6 [i']cheats[/i] and has hidden code behind the scenes (that you don't ever see) that looks something like this:Dim Form1 As Form1 Set Form1 = New Form1 Then within your code, you simply call stuff like Form1.Show(), etc without ever having to explicitly create an instance of it, because it was done for you behind the scenes. Let me put it another way: Forms are Classes. So they must be instantiated before they are used. Yes, you got it! :) All Classes have a Sub New(), which is called whenever a New Class is created. Since a Form is a type of Class, it also has a Sub New(). It does execute before the Load event, correct. Within a Form Class you should think of the Sub New() as replacing the Form_Initialize() event that used to exist in VB6. It's actually all 100% parallel. You've probably hit on almost everything that's different at this point. That said, reading your VB.Net's chapter on Form's and Controls could help too. Yeah, "solution" is pretty weak, eh? It's the equivalent of what VB6 called a "Project Group". Anyway, the EXE and the DLL within this Solution are in no way bound to each other. The "solution" is just a convenience for the programmer to see the code within the source DLL and the EXE at the same time. The key to the functionality rests within the fact that the EXE has a Refernce set via Alt|Project|AddReference... to the DLL. To test this out, create a brand new Windows Application and then goto Alt|Project|AddReference... and then Browse until you find the vbBlankClassLibrary.DLL. Once you do this you will be able to utilize the Classes within that DLL in exactly the same way. :)

Well, changing the Worksheet's column width would look something like this: Dim xlWS As Worksheet = CType(xlApp.ActiveSheet, Excel.Worksheet) xlWS.Columns("A:C").ColumnWidth = 20 I've never changed the print settings to 11x17, but I guess it would look something like this: xlWS.PaperSize = Excel.XlPaperSize.xlPaper11x17 Hope this helps... -- Mike

Unsigned Types are not CLS-Compliant, and VB.Net is designed to only create verifiably-safe code. This is the reason for the restriction. (They're fine if use Privately, however, so I can see your point...) We could go at this hammer-and-tongs, but I think that such a "discussion" is probably best in Random Thoughts... not in General where someone is just looking for some appropriate help/advice on the topic...

Cool! Very glad to hear it. :)

Sounds very cool... And what's "Flow Panel"? Still, I think that Realolman needs to be able to walk before he can run.

Is the frmMain the Startup object or is frmSplash? It sounds like after a few seconds, the frmSplash is hiding itself, but not Closing... The frmMain then Opens and is eventually Closed by the User, but the process is actually being controlled by frmSplash. This is a bit of guesswork on my part, because I don't quite know how your code is working, but this is what it sounds like to me. I would change it up by having the frmMain be your Starup Object and then you can put your code to show the frmSplach within frmMain's Load() event. Does this make sense?

Ok, let's continue with our little example and make the form into a true "Dialog Box". This form will be reusable in the sense that when it is called, when done, the Form will hold a value that the Caller can check. For instance, this could be Form that allows the User to enter his Name and then hit OK. To make it re-usable, and not "hard code" what this Form is intended to do, we'll give this Form the ability to let the Caller change the message via a new property we'll call the .Instructions property. The Caller will be able to get the results from a Property we'll call the .ResultString property. Your program could then call this Form using somthing like: Dim frmDialog As New vbBlankClassLibrary.FormDLL1 frmDialog.Instructions = "Please enter your name." frmDialog.ShowDialog() Me.Label1.Text = frmDialog.ResultString How's that for re-useable! The key is that the Instructions are not hard-coded. :) To make this possible, we do the following: (1) Add two buttons to the bottom of our FormDll1. We give them the programmatic names 'btnOK' and 'btnCancel'. We set their .Text properties to "OK" and "Cancel", respectively. (2) We then find the DialogResult property within the Properties Window and set the btnOK's value to 'OK' and we set the btnCancel's value to 'Cancel'. (3) We then use the following code: Public Class FormDLL1 Inherits System.Windows.Forms.Form Private _instructions As String Public Property Instructions() As String Get Return _instructions End Get Set(ByVal newValue As String) _instructions = newValue Me.Label1.Text = newValue End Set End Property Private _resultString As String Public ReadOnly Property ResultString() As String Get Return _resultString End Get End Property Public Sub New() ' Required Calls: MyBase.New() ' <-- Required Call InitializeComponent() ' <-- Required Call ' Our Code: Me.Instructions = Nothing Me._resultString = Nothing Me.TextBox1.Text = Nothing Me.AcceptButton = Me.btnOK ' <-- If User hits <Enter> key Me.CancelButton = Me.btnCancel ' <-- If User hits <Esc> key. End Sub Private Sub FormDLL1_Load(ByVal sender As Object, _ ByVal e As System.EventArgs) _ Handles MyBase.Load Me.Label1.Text = Me.Instructions Me.TextBox1.Text = Me.ResultString End Sub Private Sub FormDLL1_Closed(ByVal sender As Object, _ ByVal e As System.EventArgs) _ Handles MyBase.Closed If Me.DialogResult = Windows.Forms.DialogResult.Cancel Then ' If User hit Cancel, report Empty String as the User's reply. Me._resultString = Nothing End If End Sub Private Sub TextBox1_TextChanged(ByVal sender As Object, _ ByVal e As System.EventArgs) _ Handles TextBox1.TextChanged _resultString = Me.TextBox1.Text End Sub End Class Note that to create the above I had to pull the Sub New() out of the #Region "Windows Form Designer generated code" and then add our code to it. Look through the code, I think you should be able to understand it. (Even easier within the attached project so that you can trace through it within the IDE.) But the basic functionality is that the Caller sets the .Instructions() and gets the .ResultString() when done. Because the .Instructions() is a set-able property, this form is quite re-usable. We could even create real-time feedback/interaction via Events, Delegates or Interface-based callbacks. I know that that sounds daunting, but understand this code first, and then I can show you how to add an Event, it's actually very easy. -- Mike vbBlankClassLibrary.zip

Inheriting a Control is more normal... Inheriting a Form is "ok", but a little less usual. Let me give an example of where I might use Form Inheritance: (1) Let's say that I use some Subclassing to better control some of the Events that a Form has, or how some existing Events behave. (Don't worry about what is "Subclassing" at the moment, it just lets you change how a Form or Control behaves, but it usually involves a fair amount of work.) So you use Subclassing and effectively give your form a new "Event" that was not natively provided by MSFT. So far so good... Now to use this in all your Forms you have two choices: (a) Copy-paste in this code any time you wish to make use of this feature, or (b) Have other forms Inherit this Form. :) Obviously, choice (b) is cleaner and easier. And this is the point of Inheritance. (2) Scenario 2 gets into "Visual Inheritance", which sounds more like what you are doing. I'm not such a big fan of this. The idea is that you add Controls or Labels to a Form. Now any Form that Inherits from this Base Form will automatically have these Labels and Controls already on it. You can play with this, but I think that it gets pretty ugly. It can be ok if you want to create a standard "banner" or letterhead or the like on a set or suite of forms that can all inherit from this base class form that already has this formatting set... But once you start adding controls to the base form it can start getting messy fast. But it can be very useful, here's a Tutorial: Visual Inheritance Using VB .NET Standard - Part 1 Visual Inheritance Using VB .NET Standard - Part 2 However, one does not have to use Inheritance to make a Form re-usable. You can make a form that has a set of controls on it and then give it a property that gives it's result...

Hey Plausibly, yeah, I agree with the message pump... It's interesting though, because windows itself uses messaging that are effectively weak pointers. The form itself must have some sort of processing loop going on... If this processing loop is constantly accessing (or at least conditionally/potentially accessing) 'this' then that would be enough to keep it alive. So this loop is basically creating an enregistered object pointer to 'this'. What I find interesting is that such a pointer is implicitly "strong" -- there is no way for it to be a weak pointer here, even though a weak pointer really is (theoretically) what one would prefer (so that the object/form could release). But, that, of course, would be phenomenally unsafe: potentially "ripping out" the object out from under the procedure running it. Hmm... you know what, I suppose that they could have this processing loop use weak pointers... On the surface, it would seem that the constant check to see 'If WeakPointer.Target Is Nothing Then' would be a pain and make for slightly more complicated coding (and slightly slower execution), but this is no big deal for an event-handling loop, which is mostly spinning it's wheels anyway, just waiting for something to happen. Huh, so I guess maybe this could be done differently? I obviously don't know a thing about what's going on in the background here, so maybe I shouldn't even be speculating... but I think this is all interesting.

Sure no prob... I was just worried, with a thread like this it can head that way fast. :( To say that "VB is crippled" is just completely innacurate. "Feels dumbed down" is fair enough, I guess. C#'s syntax is its greatest asset: terse, concise.

Oh no, let's not start a flame war about this... if we want to we can do that in a separate thread. I think that Mookie just needs some advice here, really. Switching over to a language just so that you can use Unsigned types really isn't a good enough reason, honest.

I can't explain it any better than does Reboot in that link I posted above, which I'll repeat here: Saving and Retrieving Application Settings. I guess that the "synopsis" would be that the current .Net approach is to use a form of INI file, but that is really XML. By being XML it's a sort of universal platform. Registry settings also make it difficult for one to back up all your settings. For example, I can save all my documents, but Applications settings in the Registry are not easily backed up. If I had a crash, I could restore my stuff... but Applications settings are generally lost as they are often Registry based. I know that making a Ghost image would cover this situation, but the point is that Config files allow for settings to be saved and more easily moved from one PC to another, say having my custom settings copied from Home and Pasted at work. This is very hard or impossible with Registry settings. The negative is that the User could inadvertently (or maybe even intentionally!) mess with the settings, since this is a much more visible mechanism than is the Registry, but I wouldn't worry too much about that. If some value is a licensing setting (a license expiration date maybe?), then I would simply encrypt that value or maybe the entire config file so that only your program could read it.

Ah, ok, cool I was curious about that, however "moot" this all is! Thank guys. :)

It sounds like in your hands it could be a very good tool... But in my hands it might not be such a good idea! :p That's good info and makes sense. I wonder why the the C++ Inline calls are generally ignored then... I can think of two possible reasons: (1) Overuse by noobs like me... and the compiler guys know it and so decide to ignore such use. (2) No matter how good you are at knowing the compiler's innards, the complexity regarding optimal register usage etc. is really likely beyond what the C programmer can really know at run time... ASM would then be required to really nail this at this level. But if you really know your stuff, I can see how an Inline call does make sense. Heck, I would use it on my little loop if I could... but maybe that would be the wrong call?

Yeah, the ".Net way" now has swung back to config files and definately away from Registry settings. Reading &/writing to the Registry should only be necessary when dealing with unmanaged components. For a pure .Net App, it shouldnt' be done. The Code Library in the XVBT sister-forum has a code library sample and discussion by Reboot: Saving and Retrieving Application Settings. In simple terms though, if you only have a few settings, I don't see why using a simple file (yes ini-style even) wouldn't be fine.