snarfblam

Hmm... that is weird. The first thing that occured to me is that it may be because they are source code and potentially malicious. It will allow you to send VB6 source files and .cpp files though. Doesn't make sense to me.

Are you using option strict? (If you arent, you probably should be.) Try changing sqlCommand.CommandText = "SELECT Email_Add FROM Login where Group_HeadID = " + senderID To sqlCommand.CommandText = "SELECT Email_Add FROM Login where Group_HeadID = " & senderID.ToString When joining strings, & is usually better than + because + might be interpreted as addition rather than concatenation.

I believe that you are referring to "clipping," i.e. you draw an image that overlaps the edge of a surface, and what goes over the border is clipped off. When you create a DirectDraw surface, you can provide it with a Clipper that specifies the region to clip, either taking a form from which it can find the bounds, or explicitly providing a rectangle. The following code (from codeproject.com) is used to set the clipper of the primary surface to the region of the application's form display = DirectDraw Device using(Imports) namespace Microsoft.DirectX using(Imports) namespace Microsoft.DirectX.DirectDraw C# Clipper clip; // Create the Clipper clip = new Clipper(display); // Set the region to this form clip.Window = this; // Set the clipper for the front Surface front.Clipper = clip; VB Dim clip As Clipper 'Create the Clipper clip = New Clipper(display) 'Set the region to this form clip.Window = Me 'Set the clipper for the front Surface front.Clipper = clip Since you will probably be rendering to a backbuffer, rather than to the primary surface, you will probably want to set a clipper for your backbuffer. I don't believe that DrawFast() uses the clipper. In this case, whatever you need to be drawn using clipping will need to be drawn using the plain old Draw() function. On my computer there is no noticable speed difference. This may not be the case with lower end graphics cards.

Are you using .text or .Text? Since C# is case-sensitive, if the TexbBox class has a private member named text you will get this error. Change ".text" to ".Text" and you should be alright.

You are... looking for an algorithm to acheive the effect of the line slowly being drawn from point a to point b? If so, why not make a function to give you intermediate points within the line so that you may draw the line one portion at a time using a timer. Use a simple weighted average function to get the intermediate points, and draw the segments on a timer. Function IntermediatePoints(ByVal Point1 As Point, ByVal Point2 As Point, ByVal Segments As Integer) As Point() Dim Result As Point() = New Point(Segments) {} Dim StepSize As Double = 1 / Segments Dim StepVal As Double Result(0) = Point1 Result(Segments) = Point2 For i As Integer = 1 To Segments - 1 StepVal += StepSize Result(i) = PointAverage(Point1, Point2, StepVal) Next Return Result End Function Function PointAverage(ByVal Point1 As Point, ByVal Point2 As Point, ByVal Weight As Double) As Point Dim Result As Point Result.X = CInt(Point1.X * Weight + Point2.X * (1 - Weight)) Result.Y = CInt(Point1.Y * Weight + Point2.Y * (1 - Weight)) Return Result End Function Those might help.

To parse a hex number, you must first manually remove the "0x" from the beginning. Then you can use the Integer.Parse() function. Integer.Parse(MyString, Globalization.NumberStyles.HexNumber) The Integer.ToString() function has an overload that allows you to specify formats. You can use either the uppercase hex format specifier ("X", yields "0123456789ABCDEF") or the lower case hex format specifier ("x", yields "0123456789abcdef"). MessageBox.Show(MyInt.ToString("X"))

Well... I edited the PATH environment to include the folder above the "Bin" folder, which includes a batch that will include the bin folder... which seems to have gotten me farther in compilation, up to this new error message. http://www.geocities.com/marble_eater/errr.jpg When I tried to do it via commandline I got the following error: C:\WINDOWS|► link.exe "@C:\Docume~1\Tom\Locals~1\Temp\tmp6E.tmp" Microsoft (R) Incremental Linker Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. "/OUT:C:\VB\Cxx\bin\Debug\Cxx.exe" "C:\VB\Cxx\bin\Debug\MainForm.obj" "C:\VB\Cxx\bin\Debug\AssemblyInfo.obj" LINK : fatal error LNK1104: cannot open file 'LIBCMT.lib' C:\WINDOWS|► [/Code] I checked and it seems the file does not exist. I don't know how to do a command line compile, though, I'm just guessing here. Appearently, though, I'm having no prob calling link.exe from the command prompt.

I have cl.exe on my drive. I downloaded the vctoolkit you linked to anyways, which didn't help. I added that path that contains cl.exe to the PATH environment variable, which didn't help. I can call cl.exe from the command prompt exactly as it is listed in the error message. C:\WINDOWS|► cl.exe "@C:\Docume~1\Tom\Locals~1\Temp\tmp59.tmp" Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. cl /c /clr /Fo"C:\VB\Cxx\bin\Debug/" /nologo /W"4" /EHsc /MT /J /GR /Y- /Gd /TP "C:\VB\Cxx\MainForm.cpp" "C:\VB\Cxx\AssemblyInfo.cpp" MainForm.cpp AssemblyInfo.cpp Generating Code... C:\WINDOWS|► [/Code] I don't understand why if I can do it, #Develop can't...

You could use the following function of the DirectoryInfo class to get a list of files that match a string including standard wildcard characters (i.e. * and ?) Public Function GetFiles(ByVal searchPattern As String) As System.IO.FileInfo() 'For example Dim Folder As New DirectoryInfo("C:\\Temp\\") Dim Files() As FileInfo = Folder.GetFiles("test*.txt")

Depending on your needs, you might want to turn it into a function. Function JoinImagesVert(Image1 As Bitmap, Image2 As Bitmap) As Bitmap Dim Result As New Bitmap(Math.Max(Image1.Width, Image2.Width), _ Image1.Height + Image2.Height) Dim gResult As Graphics = Graphics.FromImage(Resi;t) gResult.DrawImage(Image1, New Point(0, 0)) gResult.DrawImage(Image2, New Point(0, Image1.Height)) gResult.Dispose() gResult = Nothing Return Result

Why not declare a variable in which to keep count for each color (provided that there is a reasonably small number of colors), and whenever you change the font color increment and decrement the appropriate variables. Otherwise, you can certainly use the code you provided, but since you have a lot of items, and you must recount the totals on the fly it might cause a small lag. Function MatchCount(ListView As ListView, Color As Color) As Integer Dim Total As Integer For Each Item As ListViewItem In ListView If Item.ForeColor = Color Then _ Total += 1 Next Return Total End Function

I've got to be honest. I use VB because I find it to be easy, yet powerful enough to suit my needs, and I am to lazy to learn anything else. I started programming when I was little, probably about ten years old or so. From Applesoft BASIC I moved to QBasic to Visual Basic to Visual Basic.Net. The .Net framework has so many features and VB.Net has all the language features that VB6 was missing, so at this point, it seems like VB will suffice for nearly anything I want to do. Unfortunately, I have very little experience with other languages. To answer your question, VB is probably best known for RAD. Commercial applications written in Visual Basic are uncommon, but one can quickly whip up all kinds of smaller apps in it. This is perfect for a company who wants to create apps for its own use. And with the .Net framework, there is a class for most anything you will need, minimizing the number of extra libraries you will need (this was often not the case in VB6). VB is also great for hobby programming.

I am trying to compile C++ code with #Develop, but I'm getting this error: http://www.geocities.com/marble_eater/err.JPG

I'm tired of it. Comparing languages, that is. All the C++ programmers think that VB is the devil, and VB programmers think that C++ is impossibly difficult. Half of these people never even give the other language a chance. I use VB because it suits my needs. Not because C++ scares me. You run into people who will tell you things like C++ is simpler than VB or worse yet that it is better in every way. And its not just C++ programmers ragging on VB programmers. Here, sometimes, it's C# and VB.Net. Elsewhere, its Java and ActiveX. Its PHP and ASP. Its Windows and Linux (well... that one I can kind of see). Each language and platform has its purpose, and it just seems to me that it shouldn't be too much to ask for an unbiased comparison of the two, rather than an insistence that one or the other is unequivocally better under all circumstances. In case anyone is wondering why I made this post, this is why...

If you want Icons (and maybe details), you could implement (or probably download source for) an owner drawn combo box.

exactly. try something like this: Sub ApplyLocalization(Collection As ControlCollection) For Each Item As Control In Collection 'Localization Code If Item.Controls.Count > 0 Then ApplyLocalization(Item.Controls) Next End Sub A recursive sub like this will automatically take care of all the controls contained within other controls. To start the whole thing up, you would just use the line ApplyLocalization(Me.Controls).

If you want to protect your source code from such reflection utilities, there are always obfuscators. Supposedly, the best obfuscators generally make your assemblies unreadable with reflection tools and can improve performance. It would seem to me that to be unable to reflect on an assembly could cause some problems, though. I've never tried one myself; they cost money.

If you want to get the bytes that make up most any numeric format, try using the System.BitConverter class. Alternatively you could create a "union" of sorts using the <System.Runtime.InteropServices.FieldOffset> and <System.Runtime.InteropServices.StructLayout> attributes on a struct. <System.Runtime.InteropServices.StructLayout(Runtime.InteropServices.LayoutKind.Explicit)> _ Structure Union_SingleByte <System.Runtime.InteropServices.FieldOffset(0)> _ Dim [single] As Single <System.Runtime.InteropServices.FieldOffset(0)> _ Dim Byte0 As Single <System.Runtime.InteropServices.FieldOffset(1)> _ Dim Byte1 As Single <System.Runtime.InteropServices.FieldOffset(2)> _ Dim Byte2 As Single <System.Runtime.InteropServices.FieldOffset(3)> _ Dim Byte3 As Single 'You can assign the bytes and read the single, or 'assign the single and read the bytes End Structure 'Even easier Dim Bytes As Byte() = BitConverter.GetBytes(MySingle)

I used Lutz Roeder's .Net Reflector, which I got here: http://www.aisto.com/roeder/dotnet/ Yes, many of the functions do additional saftey checks, but most of these safety checks one would (and should) normally do himself anyways. Either that or they are checks you normally wouldn't need. For example, the IsArray function first checks if the reference is a null reference, and if so, returns false. I personally would never think of passing a null reference to IsArray in the first place. If there was any possibility of the variable being a null reference, I would check first. And personally, I would want a null reference exception thrown if I passed a null reference to IsArray so that I would know if I were doing something wrong. (I assume that this behavior is there for consistancy with VB6, but that was just an example off the top of my head.) I have read this article, which makes some good points. I'd like to point out an inaccuracy in the article, though. It states that conversions are inlined and make no reference to the Visual Basic namespace. Some conversions can not be inlined, however, such as strings to numeric types, and vice-versa. And rather than simply calling the .Parse and .Tostring methods, they call functions in the VisualBasic namespace. Look at the IL below (this is what my CStr got compiled to). L_00c7: call string [Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.StringType::FromInteger(int32) The implicit call to the VB namespace doesn't bother me. What does bother me is the fact that they use their own function, which in turn simply calls the appropriate .ToString function. I don't see the necessity. This call to Int32.ToString could be inlined. .method public static string FromInteger(int32 Value) cil managed { // Code Size: 10 byte(s) .maxstack 3 .locals ( string text1) L_0000: ldarga.s Value L_0002: ldnull L_0003: ldnull L_0004: call instance string int32::ToString(string, [mscorlib]System.IFormatProvider) L_0009: ret } Oh, and btw, vbNewLine = Environment.NewLine. And like I said, in the past I would normally say that using Microsoft.VisualBasic is okay to use. Microsoft says it is part of Visual Basic. But when you really look at it, all Microsoft.VisualBasic is is .Net for dummies. It just wraps existing functionality with those familiar old names, and performs checks that I personally wouldn't expect or need it to do for me.

I know why its there, hence my suggestion for a MSDN article that lists .Net equivalents. The VisualBasic namespace doesn't help the learning curve much more than it would if you were to tell the VB6 programmers that so-and-so function in .Net is the exact equivalent. I suppose that my point was that it is rediculous to give programmers a set of functions that simply call another function for you. Why not just tell you the new .Net equivalents. I don't need Hex to call Int32.ToString for me; I can do that myself. I don't need Left to call String.SubString for me; I can do it myself. There are a few things where the transition is a bit more complicated (for instance, files access). These I can understand still being around, but so many VB functions simply call other .Net functions, or at best reproduce their functionality. I personally have never run into anything in the Visual Basic namespace that I couldn't do without it, and the result is usually the same amount, if not less, work and coding on my part.

I was looking at the Microsoft.VisualBasic assembly with a reflection tool, and was surprised to see that nearly everything it contained simply wrapped another .Net function or class. Microsoft's take is that Microsoft.VisualBasic is part of the Visual Basic language, and Microsoft.VisualBasic.Compatibility is the for VB6 compatability, but looking through the functions, you notice that Hex() simply wraps the .ToString method of integral data types, and the Len function just returns the String.Length property. Even the Collection class seems to basically wrap the ArrayList class. 'Why? Public Shared Function Hex(ByVal Number As Integer) As String Return Number.ToString("X") End Function 'What is this?? Public Shared Function Int(ByVal Number As Integer) As Integer Return Number End Function 'This is harldly justifiable... Public Shared Function IsArray(ByVal VarName As Object) As Boolean If (VarName Is Nothing) Then Return False End If Return TypeOf VarName Is Array End Function It seems to me that all that the Microsoft.VisualBasic namespace provides is .Net functionality with different names to make VB6 users more comforatble in .Net. I don't use the Visual Basic namespace (even though I program in Visual Basic) but when the issue comes up of whether or not it is okay to use the VisualBasic namespace, I have always taken the stance that it is still part of the language and that it is mostly a matter of the programmers preference. Now that I've seen the decompiled code, though... I am actually a bit disturbed. It simply needn't exist. How about a section in MSDN that simply lists VB6 classes/functions and their .Net equivalent? When it comes to backwards compatability and upgrading, I think everything in Microsoft.VisualBasic should be moved to Microsoft.VisualBasic.Compatability.

It is worth noting that you could easily do this with an animated gif in a picturebox, provided that the progress bar is of a fixed size. (This won't be consistend with user's xp styles/color settings, though)

I'm glad that this isn't how you guys always find an answer to other users' questions. Based on the described contents and behavior, I would say that this is exactly what mjcatt was referring to. If you are using Win Xp, go to a file's properties and note the tab labeled "Summary". I am pretty sure, however, that the .Net Framework does not contain any classes that relate to these properties. If you are talking about the alternate data streams, a google search lead me to http://www.relsoft.net/datastreams.html, which explains how ADS works. Some more googling should help you figure out how to access these properties. Just keep in mind that this is specific to NTFS (as far as I know). Don't assume all users will have this capability, and realize that you will be using pure platform invoke to do this. P.S. As pointed out by PlausiblyDamp, the summary information found in the ADS is different from summary information which may be stored in office documents, jpegs, etc.