snarfblam

First of all, I am assuming that the object raising the event is a menu item in a sub menu. If it is a top level menu item in the context menu then its parent will be a ContextMenu component, which doesn't have a .Text property. If it is a sub menu item, its parent will be another menu item. Secondly, with Option Strict On, you need to do a lot more casting and conversion. Sender is passed as an object, which does not have a .Text property. Since Sender actually points to a MenuItem, you can cast (CType/DirectCast) Sender to a MenuItem and gain access to all of its properties and methods. When you get the menu item's parent, it returns the parent as an instance of the "Menu" class. This, again, does not have a .Text property. But the "Menu" that you get from the .Parent property actually points to a MenuItem, so you can gain access to all of its properties and methods by casting. tParent = DirectCast(DirectCast(sender, MenuItem).Parent, MenuItem).Text.ToString 'sender must be cast to a MenuItem to access the .Parent property. 'DirectCast(sender, MenuItem).Parent must be cast to a MenuItem to access the .Text property. Also, since the .Text property returns a string, you do not need to use the .ToString method. Calling .ToString on a string will just return a copy of the string. To work with option strict on you need to pay close attention to types, and I recommend a good understanding of inheritance so that you know when you can cast from one class to another (i.e. MenuItem inherits from Menu, so If you have a Menu that you know points to a MenuItem, you can cast. MenuItem [and everything] also inherits from Object, so if you have an Object that you know points to a MenuItem, you can cast).

tParent = DirectCast(sender, MenuItem).Parent.Text.ToString 'sender is a menu item, right? Also CType will work equally well. DirectCast performs a little better but will not do many things such as converting strings to ints and the like, it will only, surprise, make a direct cast.

There is a difference between nearly negligible and negligible. A good optimizer recognizes this difference. And binary operators aren�t going anywhere. I am working on a program right now that has hundred of lines of binary operations performed on bytes in arrays. So of course I am aware of their importance, and would never dismiss them for their intended purpose. My only point was that swapping an xor for addition when the operation consumes essentially none of the cpu time either way is ridiculous. I highly discourage anyone from using xor instead of + or any other "tricks" like that unless he runs into a situation where he really needs speed.

Um... it should be noted that without more of the code from where the original excerpt above came from, it can not be concluded that the coder necessarily intended to use the xor operator for the purpose of addition. Jay1b did ask how it acts like a + operator, but apparently only because he realized that the result yielded by both operators was equal. Anyways, a note on optimization... I am not sure if you are trying to encourage use of code like that posted at the top of the thread, but to paraphrase something written by microsoft, i believe, micro-optimizing every line of code is a terrible waste of effort. Yes, 65 xor 50 is faster than 65 + 50, but to try to maximize power and speed on every line of code is a terrible waste of effort. Don't try to take advantage of every micro-optimization you know of. The speed difference will be negligible. You really need only focus on optimizing bottlenecks, places where large amounts of code or large loops are processed at once. If you are showing a message box it is quite pointless to try to save the user one nanosecond of his time by using an xor instead of a +. I highly discourage anyone from using xor instead of + or any other "tricks" like that unless he runs into a situation where he really needs speed.

A floodfill could be useful. I wonder why they didn't include it...

If your user wants to run it, can't he go to it in the start menu or where ever a shortcut was created and run it himself. The .NET deployment projects don't include a "Run [Your Project Name Goes Here] after setup" checkbox in the last page of the wizard, but its not the end of the world, just a minor inconvinience.

If you store all the textboxes in an array or collection so you have references to them, then you should be able to access their .Text property, no?

I thought that shared members were a different case. I changed the name of the struct and the error for the illegal initializers dissapeared. Other errors appeared though because of the reference to a nonexistant type (due to the name change) and must have caused to compiler for some reason to ignore the illegal initializers, hence my confusion.

You can use Me.Focus (this.Focus in c#) which will just focus your form (in windows xp (maybe windows me too, i forget) this will actually flash the taskbar button. Also, try using the shared System.Windows.Forms.ActiveForm. If none of the forms in your app have focus (which generally means your app doesnt have focus) the function returns nothing. So if ActiveForm() is nothing, call FlashWindowEx (or FlashWindow, whichever you are using). [Edit]I Lied. Me.Focus doesn't do what I thought it did. I was thinking of Me.Activate().[/Edit]

I have a struct named "Screen." By best guess is that my problems are somehow related to a name conflict with the System.Windows.Forms.Screen class. Here is my problem: I have shared (static in c#, i believe) members with initializers in the declaration (Shared i As Integer = 7 / int i = 7; ). I am recieving errors that "initializers on structure members are valid only for constants." When I change the name of the struct, all my errors dissapear...

Just an idea... have a label that shows the date picked, and when the user clicks the label bring up a previously hidden monthcalendar and when the monthcalendar loses focus, hide it again.

Another way to do it: via the toolbar. Right-click to toolbar, click customize, and pick "View" for the list of view related commands. Scroll down. Scroll down some more. And then some. Eventually you'll find it. It's "Navigate Forwards" and "Navigate Backwards". Two toolbar buttons that provide the same functionality. Woo hoo.

Quite right, the .Load event is called immediately BEFORE the form is shown for the first time. Any drawing you do before the form is shown will never show up. Also, FYI, the pen constructor has an overload like this (color As System.Drawing.Color, width As Single).

I had a label that used word wrap and had to be resized vertically based on the amount of text it contained. I created a graphics object and used the measurestring method to find the height (the measurestring method has an overload that accepts the maximum width). Here is my code: Dim g As Graphics = lblHelp.CreateGraphics lblHelp.Height = CInt(g.MeasureString(lblHelp.Text, _ lblHelp.Font, lblHelp.Width).Height) If you need a resusable label, you could inherit the label control, override the .Text property, and in the set block measure the size of the text as I did in the code above, and resize the control accordingly. You will also want to resize the height if the .Width property is changed. Here is a quick example: Public Class BetterAutoSizeLabel Inherits Label Private _Autosize As Boolean Public Property VerticalAutoSize() As Boolean Get Return _Autosize End Get Set(ByVal Value As Boolean) _Autosize = Value End Set End Property Public Overrides Property Text() As String Get Return MyBase.Text End Get Set(ByVal Value As String) If _Autosize Then Me.Height = CInt(Me.CreateGraphics.MeasureString(Value, Me.Font, Me.Width).Height()) MyBase.Text = Value End Set End Property End Class

The indecies of the tab pages are not going to change. I don't know if it is good practice to use tabControl1.SelectedIndex = 0, but I know it works. Also, this: tabControl1.TabPages[0].Controls[tabControl1.TabPages[0].Controls.IndexOf(textBox2)].Focus(); will work... but what this code if very redundant. it calls many functions to find the reference (address if you prefer) of textbox2, and does so by using a reference to textbox2, then brings focus to the control. My recommendation: don't use that code. It is not any safer than txtBox2.Focus(). When you want to select a control within a tabpage, set the selected tabpage (tabControl1.SelectedIndex = 0) and then set the focused control (txtBox2.Focus(); ). Thats it.

Well, I've started converting my program over to filestreams and it looks like I only have about 100 fileget/fileputs left to replace, but just in case anyone who knows the answer to the above question, I am still very curious.

Are you trying to raise an event in your own control? Are you trying to cause another control to raise a keypress event? Are you just trying to call a keypress handler function? What exactly are you trying to do?

This code makes the most sense to me: tabControl1.SelectedIndex = 0 textBox2.Focus() If you have a reference to the control (in this case the variable named textbox2), you don't need to do a for each to find the index, and you certianly dont need to use the reference of the control to find the index which you can then use in the controlcollection to... find the reference. Kind of redundant. No?

I vote that this topic be locked before this goes on for too much longer

As far as Cls compliance goes, vb.net does have jagged arrays and perhaps some other non cls-compliant features. Perhaps the unsigned integers were not implemented in vb.net is because 99.99% of users will never need or want unsigned integers. Well... honestly I have found myself irratated by the lack of support for unsigned integers, but I achieved what I wanted easily enough without them. The features left out of VB.Net never stop you from doing what you want to do and at worst they usually only make it a little more difficult, and for a lot of people their project on a whole will be easier because the syntax is meant to be easier. Things like this should not be a deciding factor between languages. It does not cripple a language. These features are left out because they dont need to be there. They arent necessary. And microsoft has a sometimes unfortunate tendancy to leave advanced features out that they think will only confuse VB users. Mookie, if you stick with VB, im sure you'll find a way to manage without unsafe code and (gasp!) unsigned integers.

The .Invalidate() function call tells the control that it needs to be redrawn, doesn't it? I get confused sometimes by control invalidation and painting and drawing, so don't yell at me if im wrong, but if you were modifying a bitmap that were persited to the panel, this would be necessary. It appears that you are using the graphics object given in the event arguments which will cause you to draw directly on the screen. Should a call to invalidate cause the control to be redrawn and erase your picture?

If you want controls that use your own graphics, you must make your own controls. The easiest, but not necessarily best, way to do this is with the UserControl. Add a UserControl to your project, and program the whole control yourself. Have fun. There may be other ways to do this, perhaps owner drawn windows controls, but... with simple things like buttons its easier to draw five pictures for different states of your control and show the text in a transparent label and show the correct image when certain events are raised.

Mono. Thats a good point. But I would say that 99% of the users here use microsofts IDE which won't build of mono. For me, for all intents and purposes, if I'm using windows forms, i can say bye to platform independance (although I do have #Develop installed on my computer).

I remember back when I was little I had an Apple //c computer, and I programmed all sorts of things in Applesoft BASIC. All there was was the command line, until I made my own GUI programs. Oh... those were the days. Seems like I spent hours just Poking and Peeking and seeing what I could make the computer do. Hey... thinking of Applesoft BASIC just reminded me of this: 10 HOME 20 SWEET 30 GOTO 10 I can't remember where I saw that though. Or why I felt so compelled to post it. Must be delerium induced by sleep depravation.

I wasn't trying to imply that c# had the same pointer funtionability as c++ but I suppose that I should have mentioned that. I also should have mentioned the speed issue, but I'm tired, its 12:30 at night. Glad you cleared it up for anyone who reads this thread.