snarfblam

Try explicitly specifying an ARGB format in the Bitmap constructor . If that doesn't work, try setting the compositing mode of the graphics object to CompositingMode.SourceCopy. The default is SourceOver, which performs an alpha blend. SourceCopy copies the alpha data instead of blending it.

Again, at the risk of sounding like a conspiracy theorist, would you really rate an article or Q&A by TC's biggest proponent as much more than propaganda? The ultimate goal is that both software and hardware be 100% TC compliant. Though not utterly horrific, the thought sickens me. It puts both users and typical programmers a long step back from hardware and raw data. For the average user this might even sound like a plus, but I enjoy this aspect of computing. TC sounds innocent enough, but I can't imagine that it could be more than marginally more secure than current software that is (properly) designed to be secure, and even if it is, I personally don't think it is worth it. It is naive to think that Microsoft's goal with TC is anything but to essentially eliminate piracy and enhance licensing (not just software licenses, but licenses on data and content) and permissions in a secure manner. (The "Trusted" in trusted computer refers more to the software vendor's ability to trust users than the user's ability to trust their computer.) That sounds like a good thing, and I am not an advocate of software piracy and I understand the need for licensing, but I think that the concept of intellectual property is far overrated. (Take a hard look at google's business model.) My concern is that I simply don't think that control of my computer should really be in anyone's hands except my own. Period. MrPaul, I understand what you are saying about those who are less computer literate than you or I. I find myself in the same situation time and time again, but a lot of malware and internet scheming will quickly find its way around TC (the core fundamentals of TC do not directly address this type of problem, despite software vendors claims that TC will help in these areas). The interest of TC lies in large software vendors, not users. There is alot to be said about trusted computing, and I don't think that it is the devil. I think that it is great for business computing. I think it is great for government computing. I just think that it is horrible for home computing and academic computing. Again, there is very much to be said about TC. It is hard to understand why I might say some of the things I've said without knowing the ins and outs of TC. I recommend you do some research and understand how it works, what the motives are behind it, and what benefits and risks it involves. Like I said, I really don't want to discuss TC on this thread, because that is not the topic of this thread (and believe me, I've only said a tiny fraction of what I think about TC). If it is to be discussed it should be done on another thread (where I will be glad to discuss it). I don't think that everyone discussing Vista really wants to read all my nonsense. Back on topic, where would I go from Windows? Most likely either Linux (the capital in the land of free software) or I will keep my x86 with Windows Xp for decades to come, like an old man listening to his vinyl records. It would be a shame to leave DotNet programming behind, because I truly love it, but I would do it for the sake of principle. Besides, that cabin in the woods sounds awfully inviting.

WinForms (and Windows, at least up to Xp, for that matter) does not support rotation of controls. You will probably have to handle the drawing of the text yourself. Perhaps you should read a tutorial on GDI+ and the Graphics object.

1) A local variable is local to each method invocation (each time you call the function a new variable is created) so there is never a conflict between threads, users, or recursive calls. 2) You save the operations of constructing an object (once) and a single push and pop operation (for each invocation). This "performance benefit" is negligible. You should use the design that is simplest or best suits your application's object model.

Note that unless you do a recursive search for controls, you will only find controls placed directly on the form (in other words, controls placed in panels and group boxes won't be found).

Well, like I said, many operations are only available on a per-file basis, so you will probably have to roll your own folder-copying function that works on file-by-file internally. I am aware that there is a Directory.Move method, but there function to copy a directory. I think there should be one, but the reason that there isn't is because all that is necessary in order to move a directory is a simple change in the FAT (which can't be done directly in DotNet code), but to copy a directory, the OS simply does a file-by-file copy, which you can do for yourself.

One thing that really bothers me about Windows Vista is that it is a big step in the direction of trusted computing. When I discuss trusted computing, I worry that I sound like a conspiracy theorist or something, but don't confuse my distaste for trusted computing with paranoia. I simply don't appreciate Microsoft's efforts to take control of my computer from me. I know that it might sound like an overreaction, but I'm not going to explain my thoughts and reasoning here because that is another topic for another thread another day. I also don't appreciate the way they worked out the versions. But, yeah, it sure does look pretty. Will I be upgrading to Vista? Probably not any time soon, and when I do, it will most likely be my last Windows upgrade.

You can use VB's TypeOf ... Is operator, like so: [Color=Blue]If TypeOf[/Color] sender [Color=Blue]Is[/Color] Form [Color=Blue]Then [/Color] [Color=Green]' Do things and stuff[/Color] [Color=Blue]Else If TypeOf[/Color] sender [Color=blue]Is[/Color] CheckBox [Color=Blue]Then[/Color] [Color=Green]' Do other things and stuff[/Color] [Color=Blue]End If[/Color] [/Code] I personally would just do a simple object comparison such as: [Code] [Color=Blue]If[/Color] sender [Color=Blue]Is Me Then [/Color] [Color=Green]' Do things and stuff[/Color] [Color=Blue]Else If[/Color] sender[Color=Blue] Is [/Color]CheckBox1 [Color=Blue]Then[/Color] [Color=Green]' Do other things and stuff[/Color] [Color=Blue]End If[/Color] [/Code]

What specifically are you trying to do? It seems like you are trying to use file specific features on a folder (DirectoryInfo does not support features such as size and access dates). Are you trying synchronize two folders (I see that you are comparing dates)? If so, your best bet might be to use a method that recurses through directories and examines and copies each file individually.

I believe the compiler has a little flexibility. If the values are mostly sequential and/or all within a small range the compiler will use a "calculated goto," the list of branches mentioned by MrPaul. I was under the impression that string-based select cases used a hashtable. The best way to find out, though, would be to compile code and disassemble it with reflector.

I'm not sure of the exact workings of the Val() function (does it throw an error in invalid values? does it ignore extraneous text?) but I am pretty sure that it can parse floating point numbers, so it is worth mentioning that each numeric type has a Parse and TryParse method (TryParse is only available on the Double type in version 1.x) so you should use the appropriate type. In other words, in addition to Integer.Parse there is Single.Parse and Double.Parse (all of which throw an error on an invalid value) and then there are corresponding TryParse methods that won't throw exceptions for invalid values.

Then perhaps it would be best to reference the old version of the assembly and use that to load the data. If it would cause name conflicts and what not, reflection would probably be a viable solution.

If you want to split a string into lines using String.Split, you might want to consider including Environment.NewLine, the CarriageReturn, and the LineFeed characters in the separators to cover all your bases (the correct line separator for Win32 is the CrLf but FTP and certain naughty apps might result in only the Cr or only the Lf).

I believe that you can check the InvokeRequired of the form containing the toolstrip (or any control, for that matter) and it should return an appropriate value.

You might be able to throw together a q&d fix, but I think your proposed solution might be along the right lines. Out of curiosity, is the issue that the type names are different or is the actual binary structure of the data changed?

IngisKahn, you know that an interface is not the same as a class definition. An interface is an intermediate step with certain restrictions. It is no huge undertaking, but one would need to search the assembly for the needed type and use reflection to instantiate it. This gets to be a pain if you are working with more complex classes or object models, but this isn't even a big issue. You lose inheritance (you gain interface inheritance, but lose class inheritance). Modifications and additions to the class must be reflected in the interface (otherwise there is no design-time or compiler support for new members). You would also have to duplicate code comments if you use them. In other words, you have to define your class interface twice to make it work. I didn't say that it was an impossible solution or that it wasn't viable. All I said was "It can work, but I don't think it would be worth the trouble."

If you encrypt the DLL you will lose a fair amount of compile-time/design-time support from the IDE and compiler. It can work, but I don't think it would be worth the trouble. I was under the impression that there were free obfuscators out there, but it seems that all the ones advertised as free are "free to try." I think that 2007 versions of VS will come with a simple obfuscator, but don't quote me on that. Short of that, there are obfuscators as cheap as $150, if not less.

Have you tried setting AutoScaleMode to Dpi? I've never really taken advantage of AutoScale, so I don't know how well it works or if you have tried it.

In terms of converting between ToolStrip controls, all Microsoft does is create a new ToolStrip control and copy over properties (and probably events, too). There is no actual class-transmutation going on. Microsoft wrote code that deals with this specific conversion and copies specific properties, and exposes this code via verbs to the designer. If you really want to incorporate this sort of "transmutational" functionality into you software in a generic manner, it would likely involve a base class for transmutable objects, lots of reflection to carry over data from one class to another, and lots of Attributes to identify how a property/field may behave during transmutation (for example, which properties are dispensible and can particular properties be converted to different types if necessary?). As far as the property grid and the CLI are concerned, you can't expect to add such a fundamental modification of the way objects work and have pre-existing code and controls integrate neatly. An important aspect of all existing object-oriented languages and platforms is that at runtime, type-related data is immutable. This is critical for the sake of marshalling, allocating arrays and memory, compile time error checking and more. This is not to say that "transmutational types" wouldn't be a nifty thing to have on occasion, but rather that they aren't really worth the trouble. In the case of the property grid, this is wholly inconvenient for your sake, but in the end this is what works.

For question number 1, my recommendation: use the String.IsNullOrEmpty method. If the value is either null (Nothing in VB) or empty, then it will return true, covering all your bases. My answer for question 2: == and <> compare the value of two objects. Is and IsNot compare to see if two variables hold the same object.

anthony, please read the Posting Guidelines. Please, (ala posting guidelines) keep it civil and do not insult or disparage members. MrPaul was trying to help, and just because the scope of his answer does not exactly match the scope of your question does not mean that it isn't helpful. Indeed, no version of Visual Basic restricts which DLLs you can and can't reference or import. From the wording of your first post, it certainly does appear that you are confused about the difference between importing and referencing. VB is different in this regard from Java. To use classes you must always reference their DLL file. Importing namespaces is a syntax feature. If the answers you have been given are insufficient you should clarify as to whether your problem is related to importing or referencing namespaces. Also, you should investigate the Express versions of Visual Studio. They are free, and for most purposes they are almost as good as the professional versions.

If they sign up with e-mails on the same domain, is it possible to block specific domains for email addresses? For example, some sites (not vB boards in particular) don't allow certain domains such as yahoo/hotmail for signing up.

You should read the license that you agreed to when you installed the software. I know that with C# Express 2003 you could freely distribute or even sell your software, just as with any other version, but the best answer to your question would be found in the actual license that was displayed in the installation wizard.

Alot of API functions can be avoided one way or another with DotNet 2.0. For instance, there are certain things that can be done with the NativeWindow class, and certain popular API functions have been wrapped, such as ExtractAssociatedIcon. Features commonly implemented through the API might possibly be doable through the WndProc method (which was present in earlier versions of DotNet as well) or something similar. The fact of the matter, though, is that if you are using an application that is heavy on (various) API calls, there isn't much point to going through your code and removing all the API calls. Generally, what new DotNet methods there are are simply wrappers and if your application isn't 100% API free then there is no gain to be had by reducing API dependancy (except, possibly, Windows version issues).

That looks about right to me.