snarfblam

I think IcePlug was simply suggesting that you create a project with a form that contains something like a few textboxes and button. Enter text to be searched into TextBox1, enter a search pattern in TextBox2, and when the user clicks the button, output the results in TextBox3.

Do you handle the SelectedIndexChanged event? If so, what do you have for code?

Whether you are looking at a .doc or a .pdf, you will need to translate the data into something a fax machine could understand. I can't tell you how to do this, but here are some thoughts. Using interop with Microsoft Office, perhaps it is possible to print to a device context or bitmap rather than an actual printer. You may also be able to find a third party library to do this. From there you can probably find a library, managed or otherwise, that can take the bitmap/DC and send it to a fax machine or a fax modem (I'm guessing that a fax modem would be easier).

Actually, the VB6 "aliases" are basically wrappers for .Net functions. You code calls MsgBox which in turn calls MessageBox.Show for you. The VB6 wrapper functions also perform safety checks, though (like checking if a reference is null before trying to call a function on it) for consistent behavior with VB6. I personally wouldn't ever knowingly pass a null reference to IsArray, for example, and if I did pass a null reference, I would like an exception to let me know, but instead it simply returns false. The reason for these functions, really, though (and I know I am contracting myself), isn't so much about the learning curve but for the sake of code compatibility, which is actually a good reason to have them. I just think that they all belong in the compatibility namespace, and to hell with programmer compatability (I know that this does not make much business sense, but I am a hobbyist programmer, not a business programmer). As far as "My," I do believe that some of the functions are inlined, but there are namespaces in Microsoft.VisualBasic.dll that perform services related to "My." Check it out with reflector. And in my opinion, actually creating a My namespace with real classes, which could achieve the same exact effect while also being available to all languages, would make much more sense. Why make it VB specific? I say it is a good idea executed horribly.

Technically, there is no ambiguity. If an overload exists, the function is called. If not, references are compared. But I am not a computer, and I can't remember every overload that exists. The ambiguity is the human factor, not a logical conflict. It comes into play when I go to see if two of my ListViewItem derived objects are the same object so that I may avoid referencing it twice in my ArrayList, but someone else overloaded the == operator to compare values instead of references so I remove the duplicate entries that I want instead of the duplicate references that I don't. The compiler knows what to do. The programmer is confused.

Finding the subdirectories should actually be pretty trivial if you are familiar with recursion (in terms of programming). As far as opening them in notepad, look into the System.Diagnostics.Process class.

As far as the IL level, The VB Is and C# == (reference comparison) are the same: they load the operands' pointers on the stack and use the ceq (compare for equality) instruction. As a matter of fact, since value comparison and reference comparison both break down to the ceq instruction, it makes sense to use == for both. That is, until == is overloaded and can break down to either a function call or a ceq instruction.

If task scheduler just can't handle your needs, there are better things to do than constantly compare time. The thread should probably spend most of it's time sleeping, hopping on once every minute or so, checking the time, and going back to sleep. This can be done with a Timer class or the Thread.Sleep() method.

This is only me guessing, but I don't think that operator overloading and "using" are there for language unification, but rather simply because they are nice features, regardless of what other languages have them. "using" has also been added to C++ (in terms of disposable objects). I'm guessing that it was a marketing ploy on Microsoft's part to leave operator overloading out of VB7 to give us another reason to upgrade to VB8 (and included in C# to give it a kick start). You have to remember that Visual Studio is as much about making Microsoft money as it is about programming. The My namespace is there for one reason only, albeit a good one: convenience. It has become very typical of Microsoft to essentially provide VB aliases for already existing .Net functionality, either for the sake of Legacy VB programmers making the transition, or for users who don't know how to search MSDN for the class they need. (Don't take that personally, VB users.)

Perhaps this is why our opinions on the subject are so different. In VB there are two operators: Is and =. Forgetting overloading for the time being, = performs comparisons on elementary types and Is performs comparisons on object references (= can not compare references). In Visual Basic you have two distinct operators to perform two distinct functions: value comparison and reference comparison. In C# there is only ==. == compares values. == compares references. In .Net 1.x, there was never an object that allowed for both value comparison and reference comparison, so it seemed to make sense to only have one equality operator. It was either an elementary type or an object, so which type of comparison we want to make is implied. In .Net 2.0, we introduce operator overloading, which allows value comparison in addition to reference comparison, and it can become difficult to tell which one the == operator is going to do. So, Nerseus and I, primarily C# users, object to overloading == on reference types because it can confuse us, and you, a VB user, don't object because in the world of VB there is no ambiguity. (Charts are fun) Comparison of VB and C# operators =================================== VB: = Operator =================================== Type Value Reference ----------------------------------- Elementary: UnBoxed Struct: Overloaded Class: Overloaded =================================== VB: Is Operator =================================== Type Value Reference ----------------------------------- Elementary: Boxed Struct: Boxed Class: Always =================================== C#: == operator =================================== Type Value Reference ----------------------------------- Elementary: UnBoxed Boxed (Must either be boxed or unboxed.) Struct: Overloaded Boxed (May be overloaded or boxed, but not both.) Class: Overloaded Always, unless overloaded (our ambiguity) So everyone is right. The only issue I can see with overloading = in VB is when the compiled code might be used by a C# coder.

A google search for vb disable screensaver yielded these results: -http://www.codeguru.com/forum/showthread.php?t=372301 -http://www.robots.epson.com/support/t34.htm -http://www.devx.com/vb2themax/Tip/19033 -http://www.vbforums.com/archive/index.php/f-43-p-7.html

This is assuming that the HTML is in the form of well-formed XML. I think that RegEx might be the way to go. You should be able to identify tags or content between tags. What you need to take into consideration is what may vary between instances of such a document. Can the table change size, or is the layout always constant. If it is always constant, you can find the beginning of the table, use regex to identify content between tags, and count in the appropriate number of tags to find the data you want. On the other hand, if the table can vary in layout your approach would need to be a little more dynamic. And then, on the other hand, the table itself at least appears to be well-formed XML, and you may be able to extract that and use some XML classes to make life easier.

You can use any CLS-compliant .dll (or an .exe in VS 2005) by adding it to your VB.Net project's list of references (right-click on the references folder and click "Add Reference...").

Just an idea: Next time you are wondering about something similar, you can always add a handler to each event and output some text to the Output Window in each handler.

There is already a function that exists specifically for this purpose (and is independant of environment, meaning it will work on a platform where the path separator character is / instead of \). Dim FolderPath As String = "C:\\Documents And Settings\\MooCow" Dim SubFolderName As String = System.IO.Path.GetFileName(FolderPath) 'Shows "MooCow" MessageBox.Show(SubFolderName) I know the function's name is GetFileName, but syntactically a folder path and an extensionless file name are the same, with one exception. A folder path can be followed by a trailing backslash, which should be taken into consideration.

Here is your problem. There is a big difference between ListView.Clear and ListView.Items.Clear (I found this out the hard way too). ListView.Clear clears all the items, all the columns, and maybe some other properties (I'm not sure). If you are looking to simply remove all items, use ListView.Items.Clear.

These are called code comments. Code comments are compiled into an XML file, in the same format as the tool tips for the .Net framework.

Even easier: System.Diagnostics.Process.Start([i]Your file here[/i])

Ouch! I'm sorry, but if you are using C++ 2003, then you are using Managed Extensions, whereas C++ 2005 uses a C++/CLR syntax. C++ 2003 won't compile the code I gave you. MyListItem should go in its own header file. Maybe you can find someone to translate the code, because I don't know managed extensions.

I recommending researching owner drawn ListBoxes. The jist of it is this: -Set DrawMode to OwnerDrawnFixed if all the items will be the same size. This probably suits you. If not, use OwnerDrawnVariable -Attach a delegate to the DrawItem event. If DrawMode is OwnerDrawnFixed, set the size by the ListBox.ItemHeight property. If DrawMode is OwnerDrawnVariable, attach a delegate to the MeasureItem event. -The event handler functions will be passed the object to measure/draw. -It may be a good idea to create your own class to hold information relevant to rendering (colors, images, etc.) Sorry if my C++ looks like garbage; clr/c++ is actually entirely new to me today. This is a class (inline in the header) I wrote to hold text and color data. ToString should be overridden because it's the function called to get the string that will be displayed in a normal ListBox. using namespace System; using namespace System::Drawing; public ref class MyListItem: System::Object { public: String^ Text; Color Clr; MyListItem(String ^DisplayText, Color c): Text(DisplayText), Clr(c){ } virtual String^ ToString() override { return Text; }; }; [/Code] This is generally what your event handlers should look like. [Code] // I used DrawMode = OwnerDrawnVariable // This function will be called to find out how big you want your items to be System::Void listBox1_MeasureItem(System::Object^ sender, System::Windows::Forms::MeasureItemEventArgs^ e) { e->ItemHeight = 16; // Change height to suit taste // Default width (100% of listbox). } //This function will be called for you to render each item System::Void listBox1_DrawItem(System::Object^ sender, System::Windows::Forms::DrawItemEventArgs^ e) { // -1 indicates no item if(e->Index == -1) return; // Get stongly typed handle to item MyListItem^ Item = ((MyListItem^)(listBox1->Items[e->Index])); // Render text e->Graphics->DrawString(Item->ToString(), this->Font, gcnew SolidBrush(Item->Clr), (float)(e->Bounds.X + 8), (float)(e->Bounds.Y + 3)); } [/Code] I added objects to the list using this code: [code] this->listBox1->Items->Add(gcnew MyListItem("Red", Color::Green)); this->listBox1->Items->Add(gcnew MyListItem("Green", Color::Blue)); this->listBox1->Items->Add(gcnew MyListItem("Blue", Color::Red)); [/Code] If it looks weird, that's because my Windows is skinned.

I'm sorry if the answer is obvious, I'm still learning. http://www.buy-printer-paper.org/images_products/37098_big.gif Take a look at the third line. That should be pushing a number on the stack for a total stacksize of two items, but when I dump the stack there is only one item on the stack. What am I doing wrong?

I've been running into this problem alot lately, especially when I design components or controls. When I open a certain form (usually one that contains my control) or click on a certain component in the component tray, my IDE will crash with no error message.

I can't explain my point of view any more clearly. Ambiguity and potential for logic errors. Here's another: breaking changes. You upgrade your component from .Net 1.1 to 2.0. You think that it would be nifty to use == to compare for equivalency, overload ==, and all of a sudden nothing works. Why? All your old code used == to check references. == has always meant the same thing for everything except elemental (or instrinsic if you prefer) types: reference comparison. Operator overloading, with the exception of ==, only adds functionality. Overloading == does not simply add function, it modifies it. The objection to overloading == is all the implications of modifying something as elementary as the definition of equality. In .Net, equality is defined (until redefined) as binary equality for simple types, reference equality for reference type, and not defined for value types, so don't break out your dictionary. I understand your point of view, I just disagree. I don't expect you to agree with me, but I have put it half a dozen ways and if you still don't at least understand then I don't know what to tell you. Also...