snarfblam

First of all, your longs should be changed to Integers. A VB6 Long is a .Net integer, and you are using VB6 declarations. Secondly, you can use masks and bitshifts to extract R, G, and B values from the 32-bit integer returned. You could also use a struct. You could also compare the integers to hex values. Here is your complete toolkit for basic GDI color operations. 'Compare to yellow 'Since GDI doesn't use ARGB, the first two digits should always be 00, i think If GetPixel(MyHdc, MyX, MyY) = &H00FF00FF Then '... 'Note that you can enter hex values in VB using the &H notation End If 'Some sample color constants Const Int32 Red = &H00FF0000 Const Int32 Black = &H00000000 Const Int32 Green = &H000000FF 'A function to do the work for us Public Function ToGDIColor(Clr As System.Drawing.Color) As Int32 Return Clr.ToArgb() And &H00FFFFFF End Function A struct! Imports System.Runtime.InteropServices Imports System.Drawing <StructLayout(LayoutKind.Explicit)> _ Public Structure MyColorStruct <FieldOffset(0)> Dim A As Byte <FieldOffset(1)> Dim R As Byte <FieldOffset(2)> Dim G As Byte <FieldOffset(3)> Dim B As Byte <FieldOffset(0)> Dim ARGB As Int32 <FieldOffset(0)> Dim UnsignedARGB As UInt32 Public ReadOnly Property ColorStruct() As Color Get Return Color.FromArgb(ARGB) End Get End Property Public Function Gdi_to_GdiPlus() As Color Return Color.FromArgb(ARGB Or &HFF000000) End Function End Structure 'You can get any of the component color values from the 'A, R, G, and B members, and a composite value from ARGB 'or UnsignedARGB. The property gets a System.Drawing.Color 'from GDI+ color values, and Gdi_to_GdiPlus gets a 'System.Drawing.Color from a GDI color value. 'Here are our .Net API function declaration: 'VB6 Longs are .Net Int32s, and IntPtr is best suited for handles 'I changed the return from GetPixel to MyColorStruct. You could just as easily use an Int32 to get raw numeric values. Public Declare Function GetPixel Lib "gdi32" Alias "GetPixel" (ByVal hdc As IntPtr, ByVal x As Int32, ByVal y As Int32) As MyColorStruct Private Declare Function GetForegroundWindow Lib "user32" () As IntPtr Private Declare Function GetWindowDC Lib "user32" (ByVal hwnd As IntPtr) As IntPtr Public Declare Function ReleaseDC Lib "user32" (ByVal hWnd As IntPtr, ByVal ByValhdc As IntPtr) As Integer I hope my answer isn't overkill, I'm just trying to be helpful.

I was wondering if you could re-use a registration code from a free license. (After you uninstall the old installation of course! We can't go around violating licenses!) I suppose they might simply disable the install (since the install downloads the program files). Maybe the details are contained somewhere in the license text.

Well, I tried the Win Api calls (my second code example) and for some reason it didn't work as expected, but the NativeWindow class is there for the purpose of subclassing windows, and from what I have seen and read, should work on your windows or those of another application, but again, it didn't work as expected. I actually gave up with the subclassing, and used another method that isn't quite so nifty, but works.

.Net introduces streams to Visual Basic. I hear rumors that streams are faster (I don't doubt it, since under the hood, FileOpen, FileGet, and FileClose probably use FileStreams), and once you get used to them, it is quite possible that you might like the way they work better. The Visual Basic file access functions are considered "bad" and "vb-ish." They aren't exactly C# friendly (it might not be a problem for you, but it could become a problem when a C# programmer wants to help you with code or you search google for help with file access and come up with C# code). Ultimately it is a matter of preference, but I thought I would just give you more options and broaden your horizon and all that happy stuff.

Well, lemme explain why I think that anonymous types fall within the scope of this conversation. It might be possible to use anonymous types without implicit typing... Rectangle MyRect = new {UpperLeft = New Point{X = 0, Y = 0}, BottomRight = New Point{X = 5, Y = 5}}; Yeah, that hurts my brain a little, but I can make sense of it. When combined with implicit typing, however... var Skoobideebop = new {UpperLeft = New Point{X = 0, Y = 0}, BottomRight = New Point{X = 5, Y = 5}}; we achieve a whole new level of unreadability. If anonymous types are vinegar, implicit typing is baking soda. But now that I'm on the subject anonymous types, it seems more than just a little inefficient to me. Look at my second code example. (This is what I found when researching on .Net 1.1, maybe, hopefully, newer versions are better optimized.) When you break down the IL, you find that you are actually creating six structs, initializing them, calling three constructors, and performing three copy operations. Now we are using properties instead of parameters to initialize our structs (because new syntax lends itself to this), adding six function calls to set property values. This is a bit of overkill to create a rect. I don't expect this to happen for a rectangle, but when people begin to tailor their classes and structs to C# syntax, which I believe they will, in certain situations it could lead to loads of anonymous types, increasing cpu usage for data initialization tenfold. It might make your code very readable, but it could also kill you in any kind of data processing if you don't know what's going on under the hood. And now I'm done complaining. Sorry I got off topic.

With the combination of implicitly typed variables and object initializers we get: var x = new { UpperLeft = new Point { X = 0, Y = 0 }, LowerRight = new Point { X = 5, Y = 5 } }; Anonymous types! Alright! We are declaring a variable of type... um... It's not that hard to figure out, but this is also a pretty simple example, and it isn't exactly intuitive. I certainly prefer: Rectangle X = new Rectangle(0, 0, 5, 5); I can't really seeing anonymously typed variables being used much, but when they are... well, there's a disaster waiting to happen. I hope that anonymous types don't make the 3.0 cut, and I would prefer that implicit typing be restricted to initializers using the new keyword (hence the variable type will be there clear as day either way), but if not, it's not the end of the world. I just can't see the benefit of typing "var" instead of "int" or "bool".

To be more precise:

Use the following code to get the streams... Imports System.Reflection '... Dim Assm As Assembly = Assembly.GetExecutingAssembly() Dim Stream As IO.Stream = _ Assm.GetManifestResourceStream("RootNamespace.Filename.withextension") 'here you can read from the stream and output the data to a filestream. Stream.Close() using System.Reflection; // ... Assembly Assm = Assembly.GetExecutingAssembly(); IO.Stream Stream = _ Assm.GetManifestResourceStream("RootNamespace.folderpath.Filename.withextension"); /* The folder path should be delimited with dots, not backslashes. Folder path is relative to the project's root folder. If the resource file is in the project's root folder, omit the folder path. */ // here you can read from the stream and output the data to a filestream. Stream.Close(); This is how it is done in .Net 1.0/1.1. As you can see, the resource naming conventions vary between C# and VB. I'm not sure that the naming convention has changed in 2.0, but 2.0 also has better tools for embedding resources, so you might want to click Help and do some MSDN research.

While there are many text editors with syntax highlighting, "intellisense," the drop down member lists and function parameter lists are pretty much language dependant, and need to be programmed for a specific language (in the case of .Net it could be done for the entire platform because of the CLS). In other words, if you want one, you will probably have to code your own.

Your method signature is wrong. e should be FormClosingEventArgs.

There should be a button in the properties window to list all the events for the object selected in the designer.

One thing that should be pointed out is that if you want to target version 1 or 1.1 of the framework, you will generally need the appropriate version of VS.

The question was to measure the refresh rate of a different program.

I suppose I should point out that even if we don't use the new features we still need to fully understand them, and new programmers still need to learn them, and if we want to use other people's code, there is a good chance that we will need to use the new features.

The .Net framework has a class, System.Windows.Forms.NativeWindow, which provides low-level encapsulation for a window. I would like to use the class to override a window's WndProc function. I would need to inherit the class in order to override the protected method WndProc(). The problem is that I need to use this class for a pre-existing window from another program, which means that I can not use the constructor, but instead I need to use the NativeWindow.FromHandle method, which will not return my inherited class, but rather a NativeWindow, hence my override will not be used. There is a function AssignHandle, but I used this function and my WndProc is not being called. Does anyone know how to use the NativeWindow class to override an existing window's WndProc? Another solution to override the WndProc would be to use the SetWindowLong API function, with which you can specify a new WndProc (I am using C#, I am just showing VB code for those who aren't bilingual): //Marshalled as 32-bit function pointer delegate int WndProc(IntPtr hWnd, int Msg, int wParam, int lParam); [DllImport("user32.dll", EntryPoint = "SetWindowLongA")] static extern IntPtr SetWindowLong( IntPtr hWnd, int Index, WndProc dwNewLong); 'Marshalled as 32-bit function pointer Delegate Function WndProc(hWnd As IntPtr, Msg As Integer, wParam As Integer, lParam As Integer) As Integer Declare Function SetWindowLong Lib "user32.dll" Alias "SetWindowLongA" ( _ ByVal hwnd As IntPtr, _ ByVal nIndex As Int32, _ ByVal dwNewLong As WndProc) As Int32 When I try this, however, I always get a null pointer for a return value, signifying an error. IntPtr OldWndProc; void SetWndProc(IntPtr hWnd) { const int GWL_WNDPROC = -4; OldWndProc = SetWindowLong(hWnd, GWL_WNDPROC, MyWndProc); } static int MyWndProc(IntPtr hWnd, int Msg, int wParam, int lParam) { } Dim OldWndProc As IntPtr Private Sub SetWndProc(hWnd As IntPtr) Const GWL_WNDPROC As Integer = -4 OldWndProc = SetWindowLong(hWnd, GWL_WNDPROC, MyWndProc); End Sub Private Shared Function MyWndProc(hWnd As IntPtr, Msg As Integer, _ wParam As Integer, lParam As Integer) As Integer End Function If anyone could figure out what I am doing wrong here, that would solve all my problems, too.

It depends on how you are passing a file. If the function is looking for a filename, then there is no way but to write the data to a file. Many functions/constructors, however, accepts streams, in addition to filenames, as a source for data, and it is possible to create a stream on a byte array (I believe that it would be the MemoryStream class). If you provide more info, we can provide better answers. Maybe show us the declaration of the function you are calling and the data you want to pass to it?

The root namespace is most likely the name of your solution, the name of your project, the name of the folder it is contained in, and the name of the executable that is produced. It is the namespace that all your types (classes, enums, structs, etc.) are located in, just as the .Net framework is located in the System namespace. The root namespace may be looked up/changed by going into your projects properties (under the "Project" menu). And, again, I don't know about resource names in .Net 2.0, but in 1.1 the name would be your root namespace (again, probably the name of your project) and the name of the file, separated by a dot (i.e. "MyProject.MyImage.bmp"). Sub folders are ignored in VB, where as they are taken into consideration in C# (for example: "MyProject.Images.ToolBarImages.Open.gif")

The Bitmap class constructor does have an overload that accepts a stream. Either way works, except that using the Bitmap constructor does not require a cast and assignment. I don't know how the resources are named in different versions of .Net but this is my favorite way to create a bitmap from a resource: Dim MyImage As New Bitmap(GetType(Me), "MyRootNamespace.MyImageFile.extension") 'Exmaple: 'I know that in VB7, resource names are 'RootNamespace.Filename (including extension) Dim imgLogo As New Bitmap(GetType(Me), "CssSoftware.Logo.gif") No finding assemblies, no loading streams. The constructor finds the assembly that the type you specify belongs to, obtains the stream, and loads the image, all in one line of code (on your part).

You are very close to contradicting yourself. Fill in some gaps and the logic clashes. As usual, the simple answer is nonsense, and I don't doubt that you know it. You can not participate in a programming community without having the same base skill set as the rest of the community, and it becomes exceedingly difficult to either make a living programming, or to make an interesting hobby of programming, without participating in programming communities. If you want your programming to be purposeful, you need to be part of the community, and you need to know the new features, hence we can not simply not use them!

PlausiblyDamp, not to say that I don't appreciate feedback, but all you shared with me is what the new features do. I'm not just some uneducated nut who is simply opposed to change. I used to program VB6. Then I tried C++. I started to tell myself that VB should have this and that. So many aspects seemed so much more intuitive to me. Then VB.Net came out and it had everything I always wanted in VB, and nothing more. I am in love with strict type checking; I daydream about inheritance. I understood the purpose of every addition to the language and the removal of everything that they took out. Perhaps my problem is my experience and the new features have very little relevance. When I read about the new features, what good they do is beyond me, and all I can see is what harm they might do. The article says "C# 3.0 introduces blah, blah and blah!" but all I can see is "disaster disaster disaster." Generics have always simply intimidated me since I never really 100% got the grasp when dealing with templates in C++, but of course I can see what good they do. I am sick of casting with ArrayLists and Stacks and Queues. On the other hand, I see class definitions becoming incredibly fuzzy as they become many levels deep in inheritance and then are extended by several different classes. I see integers and booleans being compared to null all throughout code. And to be honest, when I was looking at lambda delegates and expression trees, I was simply amazed at how little the code examples resembled C#. I am sure that you're opinion doesn't agree with mine, but at the same time I am sure that you can understand where I am coming from.

After reading this thread and reading an article, frankly, I am starting to get quite frustrated with .Net. They created something powerful and flexible yet simple. The essence of elegance. Then they tack on generics, nullable types, and partial classes. Now we have extenders, lambda expressions, implicit types, object initializers, anonymous types... We are taking C#, throwing in everything bad about VB (don't get mad, VB users, you know it has potential for horrible programming practices), adding the confusion of C++ (don't get mad C++ users, you know that it takes a lot more time to learn and requires a much finer understanding of the language to fully utilize all its features, and I'm sure you remember the utter confusion the first time you looked at C++ code), and creating FrakenSharp .Net. I don't understand extenders. Isn't the idea to inherit a class in order to extend it? And isn't the idea that a sealed class is specifically meant to not be extended? I can see where an extender can be useful, but it looks like we are losing touch with the OOP and managed code virtues that made .Net so great. What is so horrible about creating a function that acts on a specific class without adding the function to that class' interface? The extender-free code isn't really any more or less reuasble, is it? We loose the OOP syntax, but extenders aren't OOP in the classic sense, are they? When you call a delegate pointed to a function of an interface implemented by a generic class implicitly typed by object initializers, just what the hell function are you calling? What about when you unwittingly call an extender function and can't find it in the definition of the class that you are calling it for, or any bases of that class. It is like giving a whole new meaning to spaghetti code. All over again we can't tell where program control is coming from or where it is going.

// class in which i use string processing code public class myClass { // ... public static bool StringHasEvenLength(string s) { return s.Length % 2 == 0; } public static void example() { string myString = "some string"; bool even = StringHasEvenLength(myString); } } This has always worked for me. I hate extenders already.

I don't know about the original "for instance" but my example was hypothetical.