Cags

I don't know exactly how Microsoft achieved this result in MSN Messenger, but if I was going to try and achieve this result myself I do try the following steps. 1. save size / location of the form 2. set the client size to 0,0 3. start a loop - move form slightly closer to toolbar - check if at toolbar - if not loop 4. hide form 5. reset size and location (so its right for when its restored) As I say this is completely theoretical, it is possible there is a built in feature for doing this, but without research, this is the approach i would take. EDIT:- Whilst I was looking on CodeProject for something completely unrelated, I came across an article on doing this. Its done in c++, but perhaps might give some pointers to help you. http://www.codeproject.com/shell/minimizetotray.asp

Rather than guessing the time remaining you could use an alternative type of progress bar, similar to the one you see when Windows XP boots. This informs the user that progress is being made, but doesn't give an estimation of how far through the process it is. It basically allays the users fears that the program has frozen. However I suspect that to get this working you will still need the seperate thread.

Just out of interest, does this cope with punctuation? I assume it does since its called a 'word boundary'. I would have checked it out myself, but I've never used a regular expression. For example would it accept the following inputs as valid... "my favourite colours are red, blue and purple." "with a red face the boy replied "blue"." "do you prefer red or blue?"

Hmm... I'm not entirely sure I followed everything you were saying there, but by the sounds of it a custom event using a delegate could be the way to go. I've only used theses a few times, but I've found them very usefull when I've needed to perform an action in a parent object. EDIT:- Sorry it does seem like were going in circles here.

I see, if the code is called from another class does it need to select the form the same as if its called from the form?

I see your point they weren't "Technically" the same :p. It just looks really strange because no extra code is inside the while loop, hence the entire code is proccessed as part of the loop invariant, leading to a single line while statement.

I was just wondering if anything could be considered wrong with using the following... while(MyFunction()) {} Basically the functionality of the while is moved to a seperate function, am I likely to encounter any problem using this syntax, or would it be better todo... bool isSuccess = true; while(isSuccess) { isSuccess = MyFunction(); } As far as I can tell both these sections of code will perform the same, I just thought I'd put the question out incase theres something I'm missing. The last thing I wan't is for my application to start throwing random errors somewhere down the line.

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

I can personally spend days working on a project without adding functionality. I tend to spend hours refactoring in various differen't ways without being able to decide which is the best.

Hehe, I know exactly what you mean, as one microsoft executive said when they were working on last round of .Net Development, "you know, release is a feature too".

I was going to suggest that earlier, however alot of it will depend on what the initial string may look like. If for example you know its going to be a list of colours then it'll work ok. But IndexOf will pick up 'red' from say 'hatred' or 'rediculous' you could always put spaces either side but that will cause trouble if you have any punctuation in the input string.

There are a couple of other ways of achieving what you want todo. One way would be to add an event, but thats abit OTT and would still require code on the form. The easiest way is to pass a reference to the listview control as a parameter, to the class that will be changing it. This way you will be able to simply call myListView.Items.Add(object).

I had a quick look, something like the following seems to work. Might be a programming 'no, no', but as far as I can tell it will achieve the effect your after. static void Main() { Form1 splashForm = new Form1(); splashForm.ShowDialog(); if(splashForm.DialogResult == DialogResult.OK) { Application.Run(new Form2()); } }

Private Sub Form1_Closing(ByVal sender As Object, ByVal e As System.ComponentModel.CancelEventArgs) Handles MyBase.Closing e.Cancel = True End Sub Obviously that only stops it working, doesn't stop it showing up.

Thats my fault int is a C# type. Perhaps Single.Parse() would have worked better.

If int.Parse(segment) > 255 Then *NB it sounds like your using .Net 2.0 in which case you could use TryParse(), if you do however note the overload is different to Parse()

Well for anyone who saw this post and was confused. I seem to have found an answer. Several other items on the 'regularly used programs' list on the Windows XP start menu pointed to the wrong program. Some kind of indexing error seems have have made the items link to the shortcut next to them.

I assume you meant can't enter. tbInput.MaxLength = 3

Ok, I obviously wasn't thinking hard enough last time as I managed to fix it this time. Heres some stuff you need to know... Firstly drawing in the OnPaint event is not always the quickest method of achieving what you want. As a general rule I like to keep by OnPaint method as clear as possible so I do all drawing to a 'BackBuffer', which in my case is a Bitmap object. The only code I would put in the OnPaint method is as follows. protected override void OnPaint(PaintEventArgs e) { // buffer is a Bitmap object declared at the top of the form // and initialised (at least to start with) in the contructor. if(buffer != null) e.Graphics.DrawImageUnscaled(buffer, 0, 0); } Now your probably thinking well thats nice but it doesn't draw anything, in which case your quite right. So we also need to add code to draw to the buffer. The way I generally do this is by creating a method called Draw(). private void Draw() { // load buffer into a graphics object System.Drawing.Graphics graphx = Graphics.FromImage(buffer); // create objects System.Drawing.Rectangle rect = new Rectangle(0,0,this.Width,this.Height); System.Drawing.Drawing2D.LinearGradientBrush brush = new System.Drawing.Drawing2D.LinearGradientBrush(rect,System.Drawing.Color.Blue,System.Drawing.Color.Gray,System.Drawing.Drawing2D.LinearGradientMode.BackwardDiagonal); // draw to buffer graphx.FillRectangle(brush,rect); // dispose of objects to prevent memory leak brush.Dispose(); graphx.Dispose(); // tell the application to update the screen (which essential calls OnPaint) Invalidate(); } This piece of code does all the drawing operations, painting everything to the buffer. So we need to call this section of code whenever we need to change something. Now in the case of resizing the form we need todo two things. Firstly resize the buffer so that it is the right size again and secondly call the draw method all over again. private void Form1_Resize(object sender, System.EventArgs e) { buffer = new Bitmap(this.Width, this.Height); Draw(); } If you were to run the application at this stage you should notice that everything looks ok, but the Form appears to flash during Resize. This is because OnPaintBackground is called before OnPaint, in situations where you are painting all or the majority of the Control/Form you should Override this method to prevent it from drawing the background first. (alternatively you could draw as part of that method instead, but I tend to stick with the OnPaint method.) protected override void OnPaintBackground(PaintEventArgs pevent) { // comment out to avoid flicker // base.OnPaintBackground (pevent); } Right I think that covers most aspects of the method I use to buffer controls. Other people may do it differently but this method has served me well.

Retrieving the value of a textbox would assumbably be done using the .Text property which is not an event but a property. Adding a click event is reasonably simple, and there is already an example of how this is achieved in VB.Net AddHandler object.event, AddressOf methodtobethehandler

I believe the reason that 'sender as object' is used, is because this enables a single event handler to handle more than one differen't type of object. If for example you wrote an event for clearing items on a form you could do.. if(sender is Textbox) { ((Textbox)sender).Text = ""; } else if(sender is RadioBox) { // do something else } ... then attach the event to any type of control. This is only my opinion, somebody with a bit more knowledge may well correct me.

You cannot use a sub item as the DisplayMember, add another property to ABC that returns XYZObject.SomeProperty(), and use that as the DisplayMember, that should circumvent the problem.