Cags

Is it just my imagination or do clumps of the same question keep turning up at the same time? Assuming I'm understanding your question, you simply wish to access a control that was created at runtime, by using a string which represents its name. If this is the case then a search of the forums will find multiple answers to this question. To get you off the mark, the simplest solution is to loop through the controls (using recursion if you have container controls) and comparing the name of the control to your string untill you find it.

You mean storing the list of which Plugins to load? Personally I'd store it as an xml file in the app directory. This could be done as part of your general application settings (if you have them). You can generate an xml file manually or use XmlSerialisation to serialise the class.

You need to pass the variable, as described in the link mskeel posted.

I guess this depends on what exactly your Plugins do. It sounds like what you need to do is find a list of the available plugins and display this to the user. Then you only wish to instantiate (is that a word) the selected objects. The way I've done this in the past is to use 2 Interfaces instead of just one (thats assuming you are using an interface, ala the excellent example in the tutors corner). Basically you have an IPlugin and an IPluginInfo for each IPlugin object you create you also create an IPluginInfo object. This object contains information such as a name, an icon etc, plus a method called CreatePluginObject or something of this ilk. Your plugin controller then searches for these items and adds them to the checkbox list. When a user selects an item on the list you can then use the CreatePluginObject method to load in the actual plugin. I hope that easy enough to understand. It might not be the best way of doing it, but thats the approach I would take.

I'm surprised nobody has replied to this topic yet. I don't have much experience dealing with databases as the only data centric applications I've made have used XML to store data. But what I have found is that objects which employ a DataSource property generally don't update at the same time as the the actual DataSource object. Is this the problem you are encountering? The way I've normally got around this in the past is to set the DataSource property to null and then back to the DataSource object. Doing this after every update to the DataSource ensures both sets are synchronised.

I believe you can do this in VB using a module (not used VB.Net much, but thats how you did it in 6.0). It can be achieved in C# also using the static key word. It's generally a good idea to avoid this as much as possible though. Is it possible to get around this global need by passing the variable to any Form or object that requires it?

Using Marbles methods (as they were more complete than my example), you would use it as follows. Dim intCounter As Int Dim strSeatName As String For intCounter = 1 To 18 Step 1 strSeatName = "lblSeat" & intCounter DsSeating1.Clear() OleDbDataAdapter1.SelectCommand.CommandText = "select * from seating where seat_no = " & intCounter & " and perf_date = '" & lstDate.Text & "'" OleDbDataAdapter1.Fill(DsSeating1) If DsSeating1.Tables(0).Rows.Count = 0 Then Dim ctrl As Control = GetControl(strSeatName) ctrl.BackColor = System.Drawing.Color.LawnGreen ctrl.ForeColor = System.Drawing.Color.Black End If Next

The above code can be written in VB as the following... Dim myString As String = "lblOne" For Each ctrl As Control In Me.Controls If ctrl.Name = myString Then ' something here End If Next As a side note, if you post the language you are using, or alternatively add it to your signature, then you may get a response you understand faster.

Actually it's not as easy as you think. But everyone always thinks it will be, I know I did when I first started programming. As far as I know there is no way to call a control usins a string without looping. Something like the following should work. string myString = "lblOne"; foreach(Control ctrl in this.Controls) { if(ctrl.Name == myString) { // do something } }

In Windows XP the character repeat rate is alterable. Which I'm assuming is the repeat rate of the key.

To be honest I'm not sure if the repeat speed of keys varies dependent on the PC, but I would suggest it does. Well the best way forward is to have a fixed speed gameloop which checks the state of the key. It sounds like your building a multiplayer game in which case most of the processing could be done server side. Basically you'd end up with something like the following. - Clients KeyDown event sends a message to the server telling it that players pressed the button. - On each game loop the server moves the clients character. - Server then sends player positions to each client. - Clients KeyUp event sends a message to the server telling it the player has stoped pressing the button. - On each game loop the server doesn't move the clients character. The servers game loop would look something like this. while(gameAlive) { // calulates any game logic like moving players, bomb explosions etc. UpdateGameStates() // sends information back to clients UpdateClients() // waits for next permited game loop while(currentTime <= nextFrameTime) { } nextFrameTime = currentTime + frameLength } If I'm honest I'm not entirely sure how all of this would be programmed, but from the articles I've read about game development, this is the approach I would take.

Sub KeyDown If key is upArrow Then If char.CanMoveUp() Then char.Y = char.Y - movementSpeed End If ElseIf key is downArrow Then If char.CanMoveDown() Then char.Y = char.Y + movementSpeed End If ElseIf key is leftArrow Then If char.CanMoveLeft() Then char.X = char.X - movementSpeed End If ElseIf key is rightArrow Then If char.CanMoveRight() Then char.X = char.X + movementSpeed End If End If Paint() End Sub Sub Paint e.Graphics.DrawImage(char.Image, char.X, char.Y) End Sub There is no need for timers or such like becuase the KeyDown event is repeatedly called whilst the key is held down.

Just incase anyone else is considering looking at this, it's worth noting that the project was created with VS 2005 and thus cannot be opened in VS 2003.

dim path as string = "C:/path/to/file.txt" System.IO.Path.GetFileName(path) This way it will work regardless of whether the path uses "\"'s or "/"'s.

Something like this should suffice. if(tabControl1.TabPages[index].Controls[2] is RichTextBox) { RichTextBox myRtf = (RichTextBox)tabControl1.TabPages[index].Controls[2]; myRtf.DoSomething(); // where DoSomething() is the relevant method. }

VB.net can execute another exe yes, theres a couple of posts about this already, just search the forum.

I'd guess that you need to cast the object to a richTextBox before you can access its specific functions. I could be wrong though.

Foreward I recently ran into a very annoying problem whilst developing for the Pocket PC. How to create an application that was full screen? The simple answer to this is you create a Form with it's WindowState property set to Maximised and set the Menu property to null. I wasn't happy with this however as although I didn't want the TaskBar and the SIP Icon, I still wanted to allow a menu. Solution 1 Many places I looked suggested that the way to get around this was to use the SHFullScreen API. The way this works is by moving the items passed into dwState below the object with the windows handle passed into hwndRequester. I'm not going to go into too much detail, but sufficed to say I could not get this method to work to a satisfactory standard. The problem is that many things can cause the Z Order to be changed back to it's initial state which causes the SIP Icon to suddenly re-appear. One annoying thing that used to trigger this was selecting a top level MenuItem, then not selecting a child MenuItem, but instead clicking back on the form. NB. SHFullScreen is generally in aygshell.dll however it's in coredll.dll on the Pocket PC Declare Function SHFullScreen Lib "aygshell" (ByVal hwndRequester As Long, ByVal dwState As Long) As Boolean [DllImport("aygshell.dll")] private extern static bool SHFullScreen(IntPtr hWnd, long dwState); Solution 2 Still determined to come up with the effect I wanted I continued on experimenting/researching. Eventually I came across some articles which used a differen't method. Namely moving the items off screen so that the form can be resize in thier place. The solution I came up with uses the following three API Calls... [DllImport("coredll.dll")] public static extern int FindWindow(string LPClassName, string LPWindowName); [DllImport("coredll.dll")] public static extern int GetWindowRect(int hwnd, ref RECT rc); [DllImport("coredll.dll")] public static extern int MoveWindow(int hWnd, int X, int Y, int cx, int cy); The basic theory is as follows. The constructor of the class gathers the required info for each item. This information is the Handle and its Location. This information is then stored for later use. A reference to the form is stored as it's possible its handle will change. public ScreenHelper(System.Windows.Forms.Form mainForm) { _parent = mainForm; hiddenItems = new ScreenItem(); GetWindowRect(FindWindow(null, _parent.Text), ref rtFormDefault); hWndSipButton = FindWindow("MS_SIPBUTTON", null); GetWindowRect(hWndSipButton, ref rtSipButton); hWndTaskBar = FindWindow("HHTaskBar", null); GetWindowRect(hWndTaskBar, ref rtTaskBar); hWndSip = FindWindow("SipWndClass", null); GetWindowRect(hWndSip, ref rtSip); } There are two other public methods, they are ChangeItemVisibility and ResetScreen. I won't cover the code too much here as its in the file, but essentially ChangeItemVisibility accepts a flagged enum, which allows you to alter whether an item is displayed on screen or not. The ResetScreen method is very important as it replaces all the items in their correct positions. It is very important that this message is called before the application is closed otherwise the user may have to reset their device in order to get the items back. To use the class successfully in an application you will need to call ChangeItemVisibilty each time the application gets control and call ResetScreen when your application looses control. To-do this I override the OnActivated and OnDeactivated events. It's also worth noting that OnDeactivated is not called when you call Application.Exit(), so be sure to add an extra call to ResetScreen() before calling it. Afterword Well I'm no Guru, but I thought that since this problem caused me a lot of headaches, I'd share the solution I came up with. Attached is a sample project which contains my ScreenHelper class. Feel free to use it or any parts at your descretion, no guarantee implied etc, etc. Comments, suggestions, bug reports all welcome. References The following is a list of the main articles that helped me create my ScreenHelper class. http://www.pocketpcdn.com/articles/fullscreen.html http://support.microsoft.com/kb/q266244/ http://www.codeproject.com/netcf/netfullscreen.asp FullScreen.zip

Take a look at the example I give in this post, its possible it will help you. If it doesn't then I'm misunderstanding your problem. http://www.xtremedotnettalk.com/showthread.php?t=95886&highlight=buffer

I will assume you are overriding the OnPaint method of the control (if your not you should probably think about doing so), if this is teh case you should also override OnPaintBackground removing the base.OnPaintBackground(e) line of code to prevent the background from being drawn (if you don't paint the entire control you can always do a Graphics.Clear() as part of the OnPaint method). This is in my experience the biggest cause of flickering when working with GDI+.

You will have to set the Form's 'BorderStyle' Property to 'None'.

Essentailly the Items property is a public property of a collection class. To-do this yourself you need to create a strongly typed PlayerCollection class (which will implement an indexer etc. Then you add a property such as private PlayerCollection _players; public PlayerCollection Players { get { return _players; } set { _players = value; } } If you need help creating a strongly typed collection just ask, but as a starting pointer you can do it by inheriting CollectionBase.

It's quite difficult to understand a large block of code like that, especially without syntax highlighting. In future if you encase VB code in VB code tags it will help people read it. Looking at your code you don't seem to make it clear exactly where the trouble line occurs, if it occurs either after the button has been disposed or before it has been initialised this would cause that error. Edit: My bad, it's all one continuous block of code isn't it. I was assuming that the '------ seperate the code functionally, whereas its just logically for the reader. Since this is the case I can't see any reason it would have been disposed by this point. Are you certain it's that line of code causing the null reference exception not the following one?

Just to clarify, the link I posted follows the method that Marble describes. As I mentioned previously the code is in c++, but it explains the method if not the exact code.

I don't think you need a Delegate to achieve what you wish. Assuming I'm understanding you right you could do it with a property. Class Form1 Private mOtherForm as form Public Property OtherForm() Get Return mOtherForm End Get Set(ByVal Value) mOtherForm = Value End Set End Property Sub Form1_Load or Button1_Click mOtherForm.[Any property goes here] mOtherForm.ShowDialogue End Sub End Class Public Function ShowList(OtherForm as Form) as Boolean Form1.OtherForm = OtherForm Form1.Show End Function