PlausiblyDamp

You will also need to add the label to the form's controls collection. lab[People.IndexOf(p)] = new Label(); this.Controls.Add(lab[People.IndexOf(p)]);

That is the standard behaviour for MDI children - is there a particular reason you do not want it to work this way i.e. floating tool windows or similar? If so there may be an alternative to making those particular forms MDI children.

DataGrid1.CurrentRowIndex = DataGrid1.CurrentRowIndex + 1 or similar should do it.

What are the Dlls in question?

You could create the controls yourself within a container control, or alternatively have a look at tthe DataGrid, DataList or DataRepeater controls - these can take a lot of the effort out of building data driven web pages.

You could always use the TypeOf operator e.g. Dim o As Object If TypeOf o Is Pen Then 'o is a Pen handle correctly here End If however you may be better off handling the whole idea differently - is there a particular reason why a single variable could contain two different classes of objects? Often it would be much better to use a different variable for each object type. This way you can strongly type things and let the compiler identify plenty sources of error. Any chance you could post more of the code to see if it could be improved somehow?

If you remove all the delegate related stuff and was just to use Console.WriteLine("{1}", 100, 101, 102); You would be getting the output because the Writeline method takes a string followed by a number of parameters - the {1} indicates that it should display the 2nd parameter following the string (0 based offset) - if you haven't come across this before then I suggest you read up on the String.Format() method. The more confusing aspect of this is probably the delegate related stuff. the line delegate void PtrToMethod( string str, params object [] args ); defines a delegate, a delegate can be thought of as a 'Function Pointer'; in otherwords it isn't a method itself but at runtime we can assign a 'real' method to it; then we can call it as if it was a function. Delegates are always strongly typed - the one in your example is compatible with any method that takes a single string and a variable number of objects (just happens to be the same signature as Console.WriteLine) the line PtrToMethod PtrToWriteLine = new PtrToMethod( Console.WriteLine ); creates a new instance of the delegate which points to the Console.WriteLine method, from now on we can call PtrToWriteLine as if it was a normal method and behind the scenes it will invoke the Console.WriteLine method for us. The real power of this is that we could use an alternate method of display by changing what PtrToWriteLine points to at runtime. e.g. using System; class MainClass { delegate void PtrToMethod( string str, params object [] args ); static void Main( ) { PtrToMethod PtrToWriteLine = new PtrToMethod( Console.WriteLine ); PtrToWriteLine( "{1}", 100, 101, 102 ); PtrToMethod PtrToWriteLine = new PtrToMethod(this.TestMethod); PtrToWriteLine( "{1}", 100, 101, 102 ); } void TestMethod(string s, params object [] stuff) { Console.WriteLine("Second Sample {1}, more Text {0}); } } The above code uses the original, then swaps the delegate to point to the TestMethod which changes how it displays the data, notice in both cases PtrToWriteLine is called in the same way.

Remove the () from the end of None and FixedSingle - that should remove some of the errors. 'Handles' is not spelt 'Handels' - that should remove another error; also the (picSmile.Click) doesn't need the brackets around it. If any others remain what is the error message displayed either in the Task List or by the tooltip if you put your mouse over the wavy blue line?

Sorry, I was getting this thread confused with a different one :confused: If you do not have the relevant parts of Outlook installed as part of your office installation that would cause these problems however.

You are only creating the controls when the page first loads, subsequent page loads do not recreate them hence the null reference.

The app.config file is really designed for adminstrative control not end user settings. If you are running on a more secure OS (XP, win2k3 possibly win2k) a normal user should not have permissions to write to the 'program files' folder anyway. If you store settings under the user profile (directly or via Isolated Storage as mentioned by IngisKahn above) then they can take advantage of OS provided features (roaming profiles, separate user configs etc).

Rather than pass a string identifying the stored proc to the reader why not create a version that accepts a string and a variable number of parameters? The GetAllAccounts would pass no parameters, GetTeamAccounts would be responsible for creating the correct parameters and passing them to the routine. Something along the line of Function GetReader(ByVal storedProcedure As String, ByVal ParamArray parameters() As System.Data.IDataParameter) As OleDbDataReader and just add the passed parameters to the command object instantiated within the GetReader function.

What are the text values you are trying to convert to integers?

Does this error occur randomly or after the application has been running for a while or after several attempts have been made to print? If so it could be a case of you not correctly freeing up the resources you are using during the printing (Pens, brushes, graphics objects etc). Could you post the relevant printing code (or at least the bits where you allocate / free resources) as this may help people to identify the problem.

This might also indicate a permissions problem - does the ASPNET account have access to launch Outlook? Also the aspnet account might not have permissions to the Exchange Information Store.

Usually the array items are numbered starting from 0, this means if your array has 2 items then they will be 0 and 1. The .Length property returns the number of items (2 in this case). Try changing the loop start to for (int i=0; i <= objFolder.Items.Count - 1; i++)

For Each Item As Control In PanelName.Controls If Typeof Item Is CheckBox Then DirectCast(Item, CheckBox).Checked=False End If Next Item

What is the website URL? Have you tried removing the path attribute from the forms element?

Just the inner one.

Have you tried changing the 'As Long' bits in the API declarations to 'As Integer'? Under .Net Integers are now 32bits and Longs 64bits; if these declares have come from a VB6 sample then that could be a source of potential problems.

In simple terms, you can't. You could provide them with a logout button and hope they remember to click it before closing the browser down, or failing that you will have to wait for the session to expire (default 20 minutes). A more fundamental issue is why more than one person is using the same accoun, if both users need access why not have a seperate account for each?

http://www.xtremedotnettalk.com/showthread.php?t=83092

http://www.xtremedotnettalk.com/showthread.php?t=87690 may be worth a quick glance

The exam just relies on you getting enough questions correct - if you were comfortable and experienced with .Net then you could pass the exam without ever having sat on a training course at all. I would second Nerseus on this one and treat a class as a way to further your knowledge of the topic rather than as a means to pass an exam, a well delivered course should be able to fill in the blank areas outside of the printed manual and give you the chance to 'play' with the language in a safe environment (no critical code to break, no legacy code to understand, no deadlines looming as you are trying to get to grips with things) and also expose you to related tools / tricks and ideas.

If you're using C# then follow the link, if you are using VB then either wait for VS.Net 2005 or search around the internet for an add-in that allows you do this in VB (stumbled across one a while back, barely used it, can't remember anything else about it).