snarfblam

It is certainly not a joke, but it is not an entierly serious programming language. It is conceptual. It isn't there to do things with it, but rather it is there to make people think. (Either that or it really is, as stated on the title page, the product of staying up too late and drinking too much.)

I think that your best bet would be to first use regex to find the matches that would be replaced in order to identify offsets and lengths, and use that data to modify the relevant annotation data before actually performing the replacement. BTW, that is a lot of data per character (right now you are looking at 14 bytes per char). Depending on your needs, the scale of the project, and how much effort you are willing to put into it, you might want to consider putting the formatting data inline in the string (html-esque). Not only will this (with some dilligence in your coding) not cause problems with misaligned data, but allow you to specify changes in formatting instead of formatting per char.

I had the same exact problem with Windows Forms menus in VS 2003 standard. Unfortunately, it is hard thing to Google, but clearly you are not alone. Perhaps you should submit this to Microsoft as a bug. It is not desired or expected behavior and I doubt that it is a "feature." My best guess is that it is a bug that inaccurately keeps track of what needs to be serialized between the designer and the generated code.

+, -, ++, --, <, >, <<, >>, * and / are not defined either for structs or classes. There is no ambiguity in operator overloading here. == and != are not defined for structs. There is no ambiguity here. For classes (and Nerseus shares my sentiments here), == and != are already defined. When you overload the == operator for a class, you aren't adding behavior, you are modifying it, hence you introduce ambiguity. For example, a programmer writes a custom ListViewItem class and overloads the == and != operators. If he unwittingly uses the == operator to check for equal reference, he encounters logic errors. On the other hand, if he pulls them directly from a ListViewItemCollection and uses the == operator to see if two are equivalent, he will inadvertently be checking for equal references, and again encounter a logic error. + always adds things. * always multiplies. == compares references on reference types. If you overload an operator and define it to do something other than what is expected you are bound to confuse people and cause problems. (We could make an exception for << and >>, since they are probably better know as stream operators than bitshift operators in C++.) From where I stand, overloading == to compare a few fields of two objects is akin to doing something like overloading + to change the Name property of your control in that you are not simply implementing the operator for a class, you are changing what that operator does.

Recently, I dropped VB in favor of C# (kind of funny since I've been doing BASIC for over ten years, since long before it was regarded as a "real" programming language in any sense). At my bravest, I got my hands dirty with MS Visual C++ 6.0, but never got far enough to be particularly productive with it. I also tried a little 6502 assembly once (as in NES and Apple II). Neither of them were "basic" enough for me. I've always been behind in the world of web programming. I don't hold much interest in it because the systems in place are much more oblique and obscure than necessary. If you ask me, HTML and HTTP are disasters and the systems of communication between clients and servers sorely needs to be revamped. But that's just me, and I'm better at making suggestions than doing things, so I'll shut up and stop dragging the thread off topic.

This is just a conceptual thing, and it might sound silly at first, but the more I think about it the more it interests me. At the most fundamental level the mechanisms of the .Net platform, for example, the type system, object allocation and instantiation, are relatively simple (although memory management might be more of a headache). There was speak of a managed API in longhorn (which certainly didn't happen), but take the concept to the next level: computer hardware designed for an object oriented environment, with a hardware controlled type system, native support for v-tables (virtual/overridable functions), memory allocation, etc. If machine language commands were tailored to the concepts of object oriented programming, the first thing we could do is write flexible, reusable, dynamic code like the code we write in .Net, but omit JIT compilation or interpretation and remove an intermediate step. Throw in (at least partial) hardware support for memory management and you get another bonus. If current managed code can potentially rival speeds of unmanaged C and C++, imagine the kind of boost more appropriate hardware could give to managed code. And, for .Net programmers, when the platform isn't abstracted from hardware, where does that leave us with portability? Well keep in mind that, according to Microsoft, .Net's primary purpose isn't portability (and Microsoft makes the point that integration between the OS and the managed platform, i.e. P/Invoke, can give you the best of both worlds when portability isn't an issue). But also consider that the compiled code won't be significantly different from current IL and implementing an emulator for object-oriented hardware would be very similar to implementing a software-based managed platform such as Java or .Net. Of course the idea isn't very realistic anyways. The break from the current conception of computing would be too big, leaving us without backwards compatibility with current OS's and software. But I thought I would throw it out there.

You will have to iterate through the tree nodes and save them yourself. Intellisense or MSDN will make it adequately clear that there is no built-in method to save the contents of a treeview, as you will find with the majority of controls. Sub SaveTree 'You may need to add/change parameters Dim MyFileStream As New FileStream("C:\MyFile.extension") Dim MyWriter As New BinaryWriter(MyFileStream) MyWriter.Write(MyTree.Nodes.Count) For I As Integer = 0 To MyTree.Nodes.Count - 1 SaveNode(MyWriter, MyTree.Nodes(i)) Next I End Sub Sub SaveNode(BinaryWriter b, TreeNode t) b.Write(t.Text) b.Write(t.Nodes.Count) For I As Integer = 0 To t.Nodes.Count - 1 SaveNode(b, t.Nodes(i)) Next End Sub Sub LoadTree 'You may need to add/change parameters Dim MyFileStream As New FileStream("C:\MyFile.extension") Dim MyReader As New BinaryReader(MyFileStream) Dim NodeCount As Integer = MyReader.ReadInt32() For I As Integer = 0 To NodeCount - 1 MyTree.Nodes.Add(LoadNode(MyReader)) Next I End Sub Function LoadNode(BinaryReader b, TreeNode t) As TreeNode Dim Text As String = b.ReadString() Dim NodeCount As Intger = b.ReadInt32() Dim ResultNode As New TreeNode(Text) For I As Integer = 0 To NodeCount ResultNode.Nodes.Add(LoadNode(b)) Next Return ResultNode End Sub That code most likely won't compile or run, but it demonstrates the basic process of saving the contents of a hierarchal structure using recursion.

Sugar free food still nourishes, and all that sugar isn't good for you. You need to get your energy from complex carbs. Maybe if your parents fed you better growing up, you would be able to appreciate sugar free cookies. Have some carrot sticks. But, yes, I have eaten sugar free everything because I know plenty of people who think that diet/fat-free/sugar-free food is the solution to a weight problem. In all seriousness, syntactical sugar is ultimately just that. I make a distinction between something like anonymous methods, which, from an extreme point of view, could be considered syntactical sugar for extra classes with methods to pass as delegates, and something like operator overloading which makes a simple substitution of "opAddition" for a "+". Operator overloading does not really add or modify functionality. You can argue that it modifies the behavior of operators, but in reality it replaces operators with functions at compile time and doesn't really behave like an operator at all. It makes your code prettier with a simple modification of syntax but without a modification of the analogy between what your code says and what it actually does, hence the name syntactical sugar. It is nice, and I can appreciate it, but I would never ever call it necessary. I will never mind using a function named Add(). << and >> are bitwise operators in C++, but they are overloaded and generally used for streams. Obviosly you can't perform a bitshift on a stream so there isn't any ambiguity. There is no conflict in C++ and I can't imagine that there would be in VB. To be perfectly honest, when streams were introduced in VB I didn't know what to do with them because they didn't overload the << and >> operators. Dim MySteam As New FileStream("C:\\Textfile.txt", FileMode.Open, FileAccess.Write) MyStream << "There is no reason why we can't use << or >> on a stream." MyStream << Environment.NewLine << "This is on the next line." << Environment.NewLine MyStream << "Bitshift: 5 << 2" << (5 << 2) 'That last one might hurt your head, but that is messy coding, not ambiguous operators

A solution and a project aren't the same. A blank solution would contain no projects at all, while an empty project would be a project for a specified language with default compiler options with no files (and most likely, no references other than mscorlib). VB.Net 2003 standard does not come with an Empty Project template. You can always create a Console application (since this is the simplest one) and remove what you don't want. Either that or research the template system in Studio .Net 2003 and create a template for an empty project. Copying someone else's templates may involve licensing issues and not be technically legal. Looking in the template folder right now, the templates seem as simple as a subfolder in the Wizards folder that contains a Script folder with a script file for the wizard (some subtle irony for you: default.js--javascript), and a template folder with template files. Google will probably help you find the details.

The framework SDK for 2.0 comes with compilers that will target version 2.0 of the framework. There is nothing to import. The new controls can be found within the System.Windows.Forms namespace of System.Windows.Forms.dll, right along with the old ones. You can look up the names of the classes and the functions and properties they have in MSDN.

You want to dispose of the IDisposable object (in this case an image) when you are finished with it. If the purpose of a function is to return an image, you certainly aren't done with the image before you return it. So who disposes of the image? Some function must call your GetImage function, and that calling function is (generally) the function that will need to dispose of the image. If you put the image in a PictureBox, you will need to hold on to it for a while, in which case, next time you load a different image into the PictureBox, that would be when to call the Dispose method. The key is having some sort of way of knowing when an object is done with and knowing what function is responsible for disposing of it.

What difficulties are you having? What have you tried or what are you trying? Do you have a question, or are you looking for some sort of How-To or FAQ?

8000 items can't be displayed at once in the ListView. The user will see the ListView fill up and then all he would see is the scrollbar shrinking, and even that would only go until a certain point. Perhaps the best option to display the progress to a user would be to use a progress bar. Just slap it on your form, and every 10 or 100 or whatever iterations in your loop, update the progress bar. Dim FileCount As Integer = 999 Const UpdateFrequency As Integer = 10 'Realistically, once every hundred items should suffice. ProgressBar1.Minimum = 0 ProgressBar1.Maximum = (FileCount + 1) \\ UpdateFrequency ProgressBar1.Value = 0 For int i = 0 to FileCount 'Do things, and stuff. Like putting things in list-a-ma-bobs. 'And then do this. If i Mod UpdateFrequency = 0 Then ProgressBar1.Value += 1 Application.DoEvents() End If Next

If your ListView is sorted, the items may not be displayed in order, or it may be that they are not added in order. Your code (specifically the use of the 'ex' variable) assumes that as items are added they will have consecutive indecies, which may not be the case. BeginUpdate and EndUpdate will speed things up, and no you shouldn't call refresh. Also, in version 1.1 (I haven't tested other versions) while using visual styles, if you modify the contents of the ListView without first calling BeginUpdate exceptions are thrown and caught within System.Windows.Forms.dll. No exceptions will make their way into your code and it won't crash your app, but it can make debugging difficult and cause terrible lag while updating the ListView.

Also, if the "pointer," better known as a reference in .Net because it does not behave like a C++ pointer in every aspect, points to something that you don't want to treat as a string (for instance, if you want to add two numbers) you can cast to the appropriate type. Dim A As Integer = 3 Dim B As Integer = 5 Dim pA As Object = A 'Points to A (3) Dim pB As Object = B 'Points to B(3) Dim Total As Integer = CType(pA, Integer) + CType(pB, Integer) MessageBox.Show(Total.ToString()) One of the differences between a pointer and a reference is that you can't do pointer math with a reference. Also, if you create a reference to a Value type (built in types like int, double, boolean, etc., or structures) you don't get a pointer to the original variable, but instead the value is "boxed" and you get a pointer to the boxed value. In addition, if you assign a new value to a boxed value type, instead of modifying the value you point to, a reference is made to a new boxed value, which means that changes made in one reference to a value will not be reflected in other previously equal references. It will probably be easier to understand what I'm saying (I'm not sure I understood that) in this code: Dim i As Object = 5 'i points to the boxed value 5 Dim j As Object = i 'j points to the [u]same[/u] boxed value j = Cint(j) + 1 'instead of modifying the value that both i and j point to, j is assigned a newly 'boxed value of 6... MessageBox.Show(i.ToString()) '...while i still points to the original 5. In other words, don't expect .Net references to behave exactly like pointers. Generally, boxed values can be avoided. Another method will usually be more suitable, depending on what you are doing. If you need functionality closer to a pointer, you might want to create a class to hold your integer. If it is just a value that you will need to access in alot of places, you might want to declare it statically (use the shared keyword) and make a static (again, shared in VB) property to access it.

A very accurate answer depends on what exactly you are doing, and I don't quite understand what exactly you are trying to achieve. Are you looking to create a database-like functionality? Something more along the lines of a spreadsheet? To declare a variable for a two-dimensional array in vb use the following syntax: Dim MyVariable As Integer(,) To create an array and store it in a variable use the following syntax: MyVariable = New Integer(23, 9) {} 'Yields a 24 x 10 array of integers Arrays can only support a single data type, unless you declare an array of objects (this uses boxing and late binding, which are generally looked down upon). This would be similar to a spreadsheet. If you want an array that holds multiple data types, for example, a list of names with accompanying dates of birth, and annual income, you should use an array of structures. This somewhat resembles a database. 'This represents one row in a "database" Structure PersonsInfo Dim Name As String Dim Income As Decimal Dim DOB As DateTime End Structure Dim MyArray As New PersonsInfo(23) {} 'Creates an array of 24 persons info 'or a "database" that has 24 rows Public Sub AccessPeronalInfo() MessageBox.Show("Person # 14's name:") MessageBox.Show(MyArray(14).Name) MessageBox.Show("Setting Person # 8's annual income to $100.") MyArray(8).Income = 100.0 End Sub If you want to be dynamic, you have a few options. When you need more space, you can create a new, larger array and copy the contents of the old array to the new one. You can also use ArrayLists or the generic List class in .Net 2.0, which automatically resize and copy the arrays, making your life easier. Jagged arrays offer more flexibility, better memory management options, and are better optimized, but are more complicated and not CLS-compliant. You may wish to research these in MSDN. You can also use ArrayLists (or List<T>) in a manner similar to that of a Jagged array.

A context menu strip (.Net 2.0) and a context menu (.Net 1.0+) are two different components (one uses Window's built in menus while the other uses a customized Office style menu). Though they perform the same function, you should be aware that there may be differences between their interfaces.

The blue lines (along with the green lines and magenta lines) are "Snap Lines." They allow you to align edges of controls and space them consistantly, even if the controls don't align with the grid. At first I did not like this feature, but I have come to like it very much after using it a little, but to each his own. If you don't like it, go to Tools>Options>Windows Form Designer>General, and set the LayoutMode from SnapLines to SnapToGrid.

It's also a good habit if you plan on expanding your computing skills into other .Net languages because it means less to learn later on.

Keep in mind that the My keyword is exclusive to VB 2005, not VS 2005

You may want to consider using the Split() function built into the string class. Dim Parts As String() = ("2sd4-7635-9g69-4556").Split("-"c) For Each Part As String In Parts MessageBox.Show(Part) Next Using non-vb functions makes things easier for C# (or J# or C++, etc) users to understand your code, in the event that they need to look at it for some reason, and makes your code easier to translate if you ever need to. I have plenty of VB.NET code that I translate to C# when I need it, and having used common .Net functions makes life a little easier for me.

Can't you do this with a deployment project? I'm pretty sure you could in 2003.

First, let me say that I am strongly of the opinion that the growing divergence of the languages is more a form of regression than progression, contrary to the spirit of .Net, and I am not fond of the "My" keyword at all, specifically because it makes VB code incompatible with C# code. "My" is a compile time feature that uses standard functions from the standard .Net library. Any VB 8 compiler should properly compile code using the My keyword, and any .Net 2.0 library (Microsoft's, Mono, etc.) should implement the helper functions that "My" compiles down to (but in my opinion, usage of the "My" keyword should compile down to common .Net functions, not VB specific functions). Any proper implementation of .Net should fully support "My" at both compile and run time. It is just more work for the Mono team. Maybe I'm crazy, but why didn't the VB team just develop a static My class in the System namespace so that it would be fully available for all languages. Well, if worse comes to worse, there are a few third party implementations of a My class that offer all the same functionality of the VB "My" keyword.