snarfblam

I recommend you set the build action to "Content". This means that the file will be included when the software is distributed, for example, when you create a deployment project. As far as the Sub Main goes, just slap it into the code of the main form.

DiverDan, not for the sake of contradicting you, but for the sake of posting accurate information, I'm going to point out that although "Layered Windows" (used for semi-transparent forms) is only supported on Windows 2000/Xp and up, other semi-transparency using Windows Forms is a feature of the GDI+ library included with the .Net Framework and is fully supported in any .Net application. Try using the Graphics object and controls with semi-transparent BackColors on the Win9x/NT platforms and you will still see the nifty semi-transparent effects.

You certainly can draw your own UI, but understanding how transparent controls work in .Net will allow you (usually) to implement transparency effects without writing your own drawing code. When transparent controls overlap, because of the way that they are drawn, the control on top "cuts a hole" through other controls, showing the underlying form or panel in which they are contained. Therefore, if you want an image to show through a PictureBox with a transparent image, the bottom image must be rendered by .Net as part of the underlying form/panel, meaning that using the BackGroundImage property would be the appropriate mechanism. Unfortunately, in .Net, when transparent controls are moved around alot, they start to look ugly (try it and you will see what I mean). If your transparent images will just be sitting there then I recommend you do things the way you already are. If there will be alot of re-drawing and moving then you may want to implement your own drawing code, which means hit MSDN. You will need to learn about the Graphics object and Invalided event.

If a TabControl or any control within one if it's TabPages has focus then pressing Control+Tab will bring up the next tab. This is consistant with most tabbed interfaces.

I'm not sure exactly what you are looking for but you can fill rectangles with semi-transparent colors by using the Color.FromARGB function, specifying a value from 0 to 255 for opacity, red, green and blue values and then call Graphics.FillRectangle using a SolidBrush created from your ARGB color. 'I haven't tested this code Dim MyBrush As New SolidBrush(Color.FromARGB(128, 0, 0, 255)) MyGraphics.FillRectangle(MyBrush, New Rectangle(0, 0, 100, 100)) 'It should draw a 50% opaque blue rectangle 100 px by 100 px at 0,0.

Cursor.Handle (which is the same as typing Me.Cursor.Handle) returns the handle to the cursor set for the object for which you are writing code, generally a form. This means that if the cursor is over something other than the object you are coding, there is a good chance that the handle returned will not be what you are looking for. I did a quick google search and found some information here: [http://delphi.about.com/od/graphics/l/aa021004a.htm]. I only glanced over it, so I don't know how good the info is. The code is in Delphi, but the Windows API aspect should still be relevant. At least it is a start.

How about regular expressions? I don't know if it will be faster, but it's worth a shot.

There are many possible problems. Ask yourself these questions and you might find that they shed some light on your issues: Did you try to compile code consiting solely of pseudo-code? Were you drunk when you wrote the program? Is the fact that you even wrote the program simply a manifestation of your imagination? Did you type the code with your toes? Did you use voice-recognition software to enter the code into your PC? Was your PC switched on when you entered the code? Are you running Microsoft Windows 95/98/Me? (This is actually the most common cause of programs not working properly.)

'Try Direct3DDevice.Clear(ClearFlags.Target Or ClearFlags.ZBuffer, Color.Blue, 1.0F, 0) 'The C#/C++ | operator is just a binary OR operator. The "Or" keywords doubles 'as a logical and binary OR operator in VB.

For starters, screen saver settings are found in the registry under: HKEY_CURRENT_USER\Control Panel\Desktop\ That's all I can help you with.

It seems to be picking up escape sequences... kinda. If you put a "\\" instead of a "\" then a single slash will show in the resulting post. With "\" [Vb] "C:\Windows\Documents And Settings\Franky\Desktop\FolderOnTheDesktop\" [/code] With "\\" [Vb] "C:\\Windows\\Documents And Settings\\Franky\\Desktop\\FolderOnTheDesktop\\" [/code]

I am using a method nearly identical to that of a tutorial found on these forums. CompileScript, well... compiles the script. FindInterface returns an instance of the first object it finds (and there should only be one defined in the script) that implements my script interface, IScript. Public Shared Function CompileScript(ByVal Source As String) As CompilerResults 'Reference to host app's exe Dim Reference As String = Application.ExecutablePath Dim Provider As New Microsoft.VisualBasic.VBCodeProvider Dim Compiler As ICodeCompiler = Provider.CreateCompiler Dim CompilerParam As New CompilerParameters Dim Results As CompilerResults 'Set parameters CompilerParam.GenerateExecutable = False CompilerParam.GenerateInMemory = True CompilerParam.IncludeDebugInformation = False CompilerParam.ReferencedAssemblies.Add("System.Windows.Forms.dll") CompilerParam.ReferencedAssemblies.Add("System.dll") CompilerParam.ReferencedAssemblies.Add("System.Drawing.dll") If Not Reference Is Nothing AndAlso Reference.Length <> 0 Then _ CompilerParam.ReferencedAssemblies.Add(Reference) Results = Compiler.CompileAssemblyFromSource(CompilerParam, Source) Provider.Dispose() Return Results End Function Public Shared Function FindInterface(ByVal DLL As Reflection.Assembly, ByVal InterfaceName As String) As Object Dim t As Type 'Loop through types looking for one that implements the given interface For Each t In DLL.GetTypes() If Not (t.GetInterface(InterfaceName, True) Is Nothing) Then Return DLL.CreateInstance(t.FullName) End If Next Return Nothing End Function The panel for the UI is obtained by an IScript function and, for the time being, is shown in a newly generated form. Ultimately, I am going to implement a tabbed interface.

Then I would say yes. Your bin folder on the development machine will generally be the program file folder on the end user machine. I don't know what your software is going to do, but keep in mind that limited users probably won't have access to write to the global "programs" folders (for example C:\Documents and Settings\All Users\Program Files\).

Do the default instances use lazy initialization? Do you have a choice on a per-form basis as to whether their is a default for for that class? For instance, could I have a default frmMain but not waste memory and initialization time on a default frmIMayNeedTwentyOfTheseIMayNeedNone?

If you click the pause button, it is common that when you break into the debugger no code is running. You can't look at the values within a class because VS doesn't know which instance of your class to show values for (even if there is only one). It would be nice if there was a roots debug window to get access to variables in your forms and such, but as far as I know, there is no such feature.

I have begun to write a program that will allow users to write scripts in VB/C#. Their scripts are compiled to in-memory assemblies using the compilers obtained by the Microsoft.VisualBasic.VBCodeProvider.GetCompiler and Microsoft.CSharp.CSharpCodeProvider.GetCompiler methods. I have tried handling the AppDomain.CurrentDomain.Unhandled exception and Application.CurrentThreadException (from both outside and inside the script) and script exceptions are not caught by these handlers. What I want to do is catch script exceptions before they crash my program, end the script, and notify the user. How can I go about catching an unhandled exception in the script so that I can do this? I can not assume that the script writer will write unhandled exception proof code. The script can actually create a GUI in a panel that will be hosted in my application and utilize event handling, so I can not simply wrap function calls with a try/catch. Is there hope for my nifty-scriptable program?

What you are looking to achieve can be done via classes in the Design library, I believe in the System.Windows.Forms.Design namespace. You can enable/disable different sizing handles in the designer. You can also override the OnResize event and only call MyBase.Resize when you are in runtime mode. (I found this out through a google search). My recommendation would be reading some tutorials on designer aspects of control development.

If you use a movie file, AVI will be your best bet. I once had a freeware program that could create animated gifs/avis. You might be able to use Windows Media Player, or something similar. Be careful, though, a splash screen is not the meat of your program and you needn't over do it. And just because there are ways to create irregularly shaped or alpha-blended or animated splashscreens doesn't mean that there is no such thing as a rectangular, static splash screen that looks nice and proffessional.

Yes, inconsistancy with regard to the settings in the GIF (in our case, the number of times to loop) is exactly why I recommended using a very long last frame, but you certainly raised a good point. I suppose the best approach would be to animate it yourself, either through existing .Net classes, or simply by displaying a series of images. The latter concerns me, though. I am afraid that you will get a "tearing" effect.

PlausiblyDamp, I appreciate your trying to be informative, but understand that I did not start this thread without first researching the new features and reading about their pros and cons and intended uses. As far as generics are concerned: Are they useful? Of course. They offer better performance than a weakly typed collection and less code bulk than a series of class definitions for strongly typed collections. Are they sorely needed? I wouldn't say so. It isn't often that you need the performance of a strongly typed collection for unknown or very large numbers of types, and if you are truly that desparate you could create an equivalent to generics (in some aspects) by creating VB/C# code during runtime and compiling it on the fly. Much more work than a generic of course. I'm not saying generics are a bad thing. Of all the new features, generics would be the one I like the most. As far as nullabe types, sure, they certainly have their uses, but, especially with the introduction of generics, the equivalent of nullable types could be created in a struct with a boolean and a variable (which is percisely what a generic is under the hood, only without specialized syntax). I'm not saying that nullables are a bad thing. As far as partials, yeah, it can be useful. It certainly provides some advantages, but it can also make code harder to read and understand when a class is defined across multiple files. I'm not saying that partials are a bad thing. What I'm saying is that too many nice things is a bad thing. There are a million and one nice things that could be added to .Net, but you don't want to have a million and one nice things. It becomes too much. It becomes complicated. It becomes C++ (there is nothing wrong with C++, it simply lacks the elegant simplicity of .Net). Consider how much more a programmer new to .Net has to learn now. With each feature you add you add a new way to introduce bugs. I am sure that partials will make it harder to find the code causing a problem. Generics are abstract which means that potential problems may not be identified. Nullables are merely a nifty struct, but giving them their own syntax in the language unnecessarily complicates the language. Hey, If I'm the minority then by all means, throw all those nifty features into .Net. I'm a big fan of simplicity, though. I see a great amount of beauty in simplicity. I can handle the ever increasing complexity in computers and programming, but I don't have that much interest in doing so. That is why I like .Net; it is everything you need in one simple, easy to use package. Maybe if computing continues getting more and more complicated, I will break out my old Apple and go back to Applesoft BASIC.

To be honest I have yet to try a beta of Version 2 of C#/VB, but I have been reading about C# 2.0 and it scares me. It seems to me that the elegance of VB.Net/C# lies in simplicity. Both languages are particularly easy to use and at the same time very powerful and flexible. But now we introduce generics, partials, and nullable types. If we continue to load these "nifty features" onto the .Net Framework/C# it won't be long before we might as well be using Managed C++. Separating designer generated code from hand written code sounds great, but it is hardly necessary; it is already collapsed into a single line in the code editor. And I can see potential there to confuse a new programmer who never had to define a class in a single file. Form1.Designer.cs will be like this mysterious black box that creates your form for you. You will never look at it, and you will be unable to create your own form by hand because you have never been exposed to that kind of code. Just like the good ol VB6 days. I personally have run into a handful of situations where I had to hand-tweak designer generated code (mainly code for forms that contain a control that I am developing). Will the possibility of doing so even occur to someone who hasn't used C# 1.x? Nullable types do not provide any new functionality. Instances where you need them are not that common, and surely a programmer can handle declaring their own boolean to tell them if a variable holds a meaningful value. Then, nullables add confusion in certain circumstances, like boxed nullable value types, where we can have a null reference, a null value, or a normal value. void NullableConfusion() { int? X = null; if (ConfuseMe(X)) MessageBox.Show("Was X a null reference or a null integer?"); } bool ConfuseMe(Object Nullster) { return (Nullster == null); //Does this perform the == operator on Nullster as an Object or a nullable int? } And generics? Well, they seem nifty, I suppose. Sure, they are flexible, but I certainly wouldn't say that they are necessary. I have yet to run into a situation where I could not make a program do what I needed it to without one of these new features. If I don't like them, don't have to use them, though, right? But the entire programming community will be and I will not be able to operate as a programmer without reasonable familiarity with these features. I will be using other people's code with these features in them. When I ask "How do I...?" on the XTreme .Net forums, someone will say "Oh, just make a generic that..." Avoiding these new features is possible but not practical. I like nice things, but I'm not big on gadgets. These new features strike me as little more than unnecessary gadgets. More ways to do the same thing. Sure, sometimes they will provide a better way, but you have to draw the line at some point; you cannot have infinitude of program features so that every task can be performed using the absolute best method (at that point we might as well be writing in assembly). I personally draw the line at .Net version 1.1. That doesn't leave much room for improvement, but maintains the simplicity that makes .Net as great as it is. To be frank, I don't see a need for improvement in the CLR. Maybe some new classes and changes in existing classes would be nice, but beyond that I don't see VB/C# 1.1 as lacking in any way. All that said, I can't really see with great certainty what kind of impact these new features will have on .Net programming until I see them in action, and I do plan on buying C#.Net 2005.

The CreateGraphics method, um, creates a graphics object for you. You do not have to use the New keyword. 'Wrong: You are passing a graphics object to the graphics constructor '(If you look at intellisense or the object browser, you will see that graphics has no ' public constructor). g = New Graphics(prender.CreateGraphics) 'Right g = prender.CreateGraphics()

Add it from the toolbox, set the Enabled property to true, set the interval accordingly, and in your code, handle the Timer.Elapsed event, which fires when the interval you have set has passed. In the elapsed event you might want to disable the timer (Timer.Stop) so that it does not continue to fire the Elapsed event.

I would add a timer with an interval of 10000 milliseconds (10 seconds). When the Elapsed event fires, hide the splash screen and show the main screen. Just a note about splashscreens: They are generally there to keep your eyes busy while the program loads. When they are unnecessary, I tend to get very much annoyed by them, and I know that I am not the only one.

The first exception thrown will always freeze the framework for a few seconds. A whole bunch of things are jitted and set up for exception handling at that point. This generally happens regardless of the build. The behavior you observe, sjn78, strikes me as unusual. After the first exception all other exceptions generally execute very fast. They are, though, as the name indicates, for exceptional circumstances only, and NOT for program flow. Microsoft has little concern for the pause caused by the first exception because they should be few and far between. TripleB gave a good sample of the "proper way" to do it. This is basically the same thing as TripleB's code, just in VB. Sub SetText(Text As String) If Not (MyTextBox Is Nothing) Then 'If the textbox exists MyTextBox.Text = Text Else 'You might want to respond to the fact that part of the 'program is trying to assign text to a non-existant textbox. End If End Sub [Edit]Just a note: Using exceptions for program flow also becomes very annoying if you are debugging and the debugger is set to break on all exceptions. Using excpetions only as they are meant to be used makes debugging very easy.[/Edit]