Derek Stone

Public Delegate Function CallBack( _ ByVal hwnd As Integer, _ ByVal lParam As IntPtr) As Boolean Public Declare Function EnumChildWindows Lib "user32" ( _ ByVal hwnd As Integer, _ ByVal lpEnumFunc As CallBack, _ ByVal lParam As Integer) As Integer Public Shared Function ReceiveWindowHandles(ByVal hwnd As Integer, ByVal lParam As IntPtr) As Boolean 'Receive handles here End Function 'Call EnumChildWindows as such: EnumChildWindows(Me.Handle.ToInt32, AddressOf Me.ReceiveWindowHandles, 0) Note: I used integers above instead of .NET's IntPtr type for the window handles. Either way, it works fine, as IntPtrs will simply be converted into 32-bit values anyway. Also, most of what's above is off the top of my head, so don't sue me if it doesn't work perfectly.

You can retrieve the resolution of the primary monitor on a system by reading the following property: System.Windows.Forms.SystemInformation.PrimaryMonitorSize() Changing the resolution will require a Win32 API call, and I don't recommend going that route anyway. Instead, prompt the user to change the resolution manually and then restart the installation.

Well that's the thing. The term "application" has to be scaled to accurately coincide with the size of the project being dealt with. If you feel that a site is best suited to fit into one application then that might just be the best solution. Nowadays though even personal websites seem to include their own forum, guestbook and t-shirt store (which disgusts me by the way) and each one of those deserves its own separate space. However, if all the site is serving is static content then the divisions usually don't have to be quite as clear. I can express my opinion on this until I turn blue in the face, but it's up to you to decide. You have good judgement. Trust it. :)

I'd strongly suggest reconsidering the use of dynamically created controls. Any programmer, regardless of the language he or she uses, will warn you against doing this. More often than not you'll have to produce some God awful spaghetti code, decreasing efficiency and readability, and creating an application that is far from reliable. I've yet to see one situation where dynamically created controls are absolutely needed, whether it was in regards to a Windows application or a web page. There has always been another solution, and I doubt this is any exception. Just keep that in mind. If you do insist on going ahead with this, look into creating parent controls for each set of like textboxes or labels. Don't mix control types inside one parent, as this is only going to lead to pain and heartache later on. The key here is to restrict the dynamic controls to their own sad little world, not letting them affect their static counterparts. Of course, once the data is submitted, you'll need to retrieve and process it somehow. Do this by looping through the Controls collection of the parent object that contains the controls whose value you need to read. As I said before, keeping the dynamic controls separate will make this part of the process rather easy. Continuing on, you'll need to associate these values with what they represent. If the user input "John Doe" you'll obviously need to feed that into the associated variable that requires that data... and so on an so forth for each control. Now, you can choose to associated each control to it's associated variable via its Tag property or by parsing each bit of incoming data and determining where it belongs. This is the part that gets ugly, and the very part that makes any sane human being want to avoid the idea of dynamically controlled input like any decent human being would want to avoid the plague. But hey, that's your choice. Some people enjoy illness... :) Someone else will be around to post an example, as I'm tight on time.

You can store the text along with its formatting in string like so: Dim sText As String = RichTextBox1.Rtf string sText = RichTextBox1.Rtf;

A DataSet can include multiple tables, as you mentioned, along with relations and key constraints, which are very useful if your database is correctly normalized. DataSets are also incredibly easy to pass between your application's different tiers, from function to function or across a serialized stream. DataReaders are limited to groupings of rows, either from a single table or two or more tables being joined together, and can't be passed around as a DataSet can be. Both the DataSet and the DataReader have their purposes, however the DataSet is used quite a bit more throughout the majority of .NET examples and documentation, primarily since it binds so easily with the DataGrid control. My advice? Use the one that does what you need it to.

I believe the RichTextBox class along with its SaveFile and LoadFile methods should work quite well for that, if I understand you correctly.

re: Robby Generally speaking it's a good idea to split up large projects into multiple parts, divided by functionality and purpose. It becomes clear after working on a sizable project that code separation is the only correct method of organization. Applications, including websites, become less scalable when they're confined to a single file, since changes to one feature often affect another. Making these code divisions is an absolute necessity if more than one developer is working on a project, however it becomes less important if the development is being done by a single person, or if the project is of a personal nature. Regardless, the industry accepted standard is to separate by application-- an application being defined as a set of pages or functions that operate together to perform a specific task. In the case of a website, we could define one application as "products" and another as "customer support", each one moving the site's users toward one focused end-goal-- either purchasing a good or service, or getting assistance with that good or service. Just like it doesn't make any sense to group a billing team with a customer support team, it doesn't make any sense to group their webpage counterparts as one either. In your case, I can foresee you combining like pages (out of the 20-or-so you said there originally were) into 4-6 pages and their associated code-behinds. This creates a maintainable yet fairly compact website. And while I agree with you on your distribution comment I can't see how one page would decrease coding time or complications when it comes to data transfer. Care to elaborate on that?

I guess I'm so use to waiting anyway (dial-up) server-side validation doesn't bother me much. I guess I can agree to a combination of both though, however redundant it may be.

This is a known problem. The search indexes where never cleared out after we transferred data to this site. Please bear with us until we get it fixed.

See, that's where we differ. I can't stand JavaScript, period. I do all my validation server-side, where it's more secure and more options are available.

re: divil Nope. I use Request.Form() to access form elements. For example: <% Dim strMessage As String If Request.HttpMethod = "POST" Then Dim s As String s = Request.Form("foobarTextBox") Else 'Page was not POSTed back End If %> <!-- Various header and body tags --> <form name="exampleForm" method="post" action="example.aspx"> <input name="foobarTextBox" type="text" maxlength="254" size="40" /> <input name="submitButton" type="submit" /> </form> <!-- Various footer and body tags --> In other words we don't touch the runat attribute for form elements (I do however use it for Web Controls).

You might want to start in [mshelp=ms-help://MS.VSCC/MS.MSDNVS/cpref/html/frlrfSystemEnvironmentClassTopic.htm]System.Environment[/mshelp].

How do I code the pages with regular HTML? Very easily. The entire EliteVB site is done in CLASP.NET, short of one or two pages which are so self-contained that I figured I suck it up and use the Web Form elements. Keep in mind though, that both myself and Garrett still take advantage of Web Controls (our own custom made ones), Code Behinds, precompilation and of course the wonderful .NET languages, we just don't care for the visual side of ASP.NET. Comments?

You know, ever since I started using ASP.NET in a production environment, I have stayed away from all the built-in server and HTML objects (Web Form controls), preferring to use raw HTML to display elements. In part I do this because I'm an avid XHTML promoter, which the framework doesn't abide by, but also due to the useless layers of Javascript and hidden form elements that are thrown on every page. I love the .NET backend, but the way pages are displayed just disgusts me. What I'm trying to get at, is this something a lot of us do, or am I in the minority here? Also, do you think it's a waste to be programming in ASP.NET when one chooses to ignore Web Forms?

It's going to take forever, since you're essentially taking what could be millions of bytes of data all in one big chunk. I really don't see any need for doing this. Take smaller chunks at a time.

Split the information up onto different tabs of a TabbedDialog control. Using scrollbars on a form is neither a standard nor acceptable method of displaying large amounts of information.

You really should not be using a COM component in .NET. The MSFelxGrid is a COM component. Check out the DataGrid instead. [mshelp]ms-help://MS.VSCC/MS.MSDNVS/cpref/html/frlrfSystemWindowsFormsDataGridClassTopic.htm[/mshelp]

Data binding definately should not be used in web pages. Reasons of security and lack of validation are just two of many. Try going at it using a DataAdapter, and if you need help doing so we're only a few clicks away.

http://www.mysql.com/articles/dotnet/

MySQL can work with .NET. It just takes some doing. http://www.mysql.com/articles/dotnet/

[mshelp]ms-help://MS.VSCC/MS.MSDNVS/cpref/html/frlrfSystemWindowsFormsDataGridClassTopic.htm[/mshelp]

The DataGrid control should work quite nicely.

Public Sub New() MyBase.New() 'This call is required by the Windows Form Designer. InitializeComponent() 'Add your code here <-<-<-<- End Sub

You don't send mail in .NET using Outlook. Take a look at the System.Web.Mail namespace instead. [mshelp]ms-help://MS.VSCC/MS.MSDNVS/cpref/html/frlrfSystemWebMail.htm[/mshelp]