|
I've come across this question before. I can't remember if it was here or some place else. The problem is the click causes the textbox to place the cursor and clear the selection. This undoes the select all you are attempting to do on the click event. I don't recall discovering a slick way around it but I did figure out a solution.
What I did was called a procedure asyncronosly. The procedure called thread.sleep for just a few milliseconds, which in practice wasn't necessary, but I figured better play it safe. After that it called selectall. Because the procedure is called asyncronosly it fires after the textbox has done it's normal thing of placing the cursor. Thus the highlighting happens after that event and "sticks".
I'm sure you could actually do this with a timer as well. Just set the timer to fire after 10 ms or so and when it does call selectall. This should create the same delay.
|
|
|
|
|
You didn't have to go through all this at all.
If you override the OnClick method, all you had to do was this:
Protected Overrides Sub OnClick(ByVal e As System.EventArgs)
' Call the base TextBox class' OnClick method so it does it's work.
' This also fires the Click event for our control so the form can
' handle the event if it wants to.
MyBase.OnClick(e)
' Then do what we really want it to do, AFTER the base TextBox does
' what it needs to.
MyBase.SelectAll()
End Sub
|
|
|
|
|
Where are you performing the override, in other words how do you tell it that it is the Textboxes event and not some other controls event?
CleaKO
"Now, a man would have opened both gates, driven through and not bothered to close either gate." - Marc Clifton (The Lounge)
|
|
|
|
|
I believe the assumption was you were creating your own custom textbox. You can only override the event if you create your own class that inherits from textbox. Correct me if I'm wrong but you want to select all when the textbox recieves focus, right? If your selecting all on a normal click it should work just fine.
|
|
|
|
|
You create your own custom TextBox class, inheriting from TextBox. I do this all the time to get all kinds of functionality I want out of the stock controls. It amazes me that people will readily do this for other classes, but rarely do it using controls.
Public Class NumericTextBox
Inherits TextBox
Protect Overrides Sub OnKeyPress(ByVal e As System.Windows.Forms.KeyPressEventArgs)
' For some reason Keys.Back doesn't work for backspace, even though it's constant is 8!
If Char.IsNumeric(e.KeyChar) OrElse e.KeyChar.Equals(Keys.Delete) _
OrElse e.KeyChar.Equals(Convert.ToChar(8)) Then
' It's a key we'll allow, so let the base TextBox handle it normally.
MyBase.OnKeyPress(e)
Else
' Drop the key by not passing it to the base class. Pass Handled back up the chain.
e.Handled = True
End If
End Sub
' GotFocus is for when the user tabs into the TextBox
Protected Overrides Sub OnGotFocus(ByVal e As System.EventArgs)
' Let the base TextBox do it's thing first.
MyBase.OnGotFocus(e)
' Then we'll select all the text.
MyBase.SelectAll()
End Sub
' If the user clicks anywhere in the TextBox, select all the text in it.
Protected Overrides Sub OnClick(ByVal e As System.EventArgs)
MyBase.OnClick(e)
MyBase.SelectAll()
End Sub
End Class
You don't have to create a new project to do this, but I highly recommend doing it. This way, the control is reusable in any project with a simple reference to this project.
|
|
|
|
|
Actually you don't need to override the click event to get select all to work. The click event fires late enough that select all will work just fine when added to that event. I mis-spoke in my post. The problem wasn't selecting all when the user clicks a textbox. The problem was selecting all when the textbox gets focus ie. The Internet explorer address bar. I believe this is what the OP wants. Currently if the textbox got focus by the user clicking on it the highlighting would be undone by the click. Tabbing worked just fine however.
The focus event unfortunatly fires to early causing the select all to be undone (again only when clicked). Delaying the select all was the easiest solution as far as I could tell.
You could also respond to the click event which fires late enough but clearly we don't want to select all on every click. So you need a global boolean to see if the textbox just recieved focus, which would be the only time you'd want to select all. Unfortunatly because we are handling this in the click event we aren't handling the focus recieved by tabbing. Thus additional code would be required in the focus event also. The delayed approach to me seemed the most straight forward and cleanest. Plus it had the added benefit of easily being able to handle one or multiple textboxes even if a custom textbox wasn't going to be created. If I missed the obvious please let me know. But the delayed method just seemed cleanest in my opinion and was just as trivial to pull off.
-- modified at 12:00 Tuesday 15th May, 2007
|
|
|
|
|
TwoFaced wrote: Actually you don't need to override the click event to get select all to work. The click event fires late enough that select all will work just fine when added to that event.
Yeah, but I believe in encapsulating the functionality I want into the control and not cluttering up my form code to get a control to do what I want.
TwoFaced wrote: The focus event unfortunatly fires to early causing the select all to be undone (again only when clicked). Delaying the select all was the easiest solution as far as I could tell.
This is also a reason to create your own control. You get greater flexibility over what you need to do when to get your functionality to work properly.
|
|
|
|
|
Good points. I guess I just assumed the OP wasn't creating a custom control. Perhaps he is or should.
However the problem still persists. The OP wants to select all when the control gets focus. So the question is what's the cleanest easist way to accomplish this? Using BeginInvoke to call a procedure asncronosly will definitly work as that's how I pulled it off before. However I realize now it can probably be done with less code if the click event was handled instead. We'd still need to select all when the user tabs so that code would need to additionally appear in the GotFocus event. Either solution would work and are the only two I can see.
|
|
|
|
|
I just showed him the basic technique in that code sample. It's up to him to implement the functionality he wants in the events he wants.
|
|
|
|
|
I need this in a Windows app not a Web app. Sorry for the confusion.
CleaKO
"Now, a man would have opened both gates, driven through and not bothered to close either gate." - Marc Clifton (The Lounge)
|
|
|
|
|
TwoFaced wrote: But the delayed method just seemed cleanest in my opinion and was just as trivial to pull off.
It's just plain bad practice to put a thread to sleep so a UI elemnt can update. I don't believe in putting in Thread Sleeps anywhere for any reason other than to wait a certain amount of time to repeat a task.
Also, your method leave your control open to failure. If the system gets very busy, your thread sleeps then wakes up, but the process you're waiting on hasn't had a chance to execute. Even if it happens just once out of a thousand times, that's one too many, and it'd be a bitch to debug.
Your method doesn't take into account future changes to the base controls either. Mine, on the hand, doesn't care what the base control does. It patiently waits for the base control to do whatever it wants, for however long it wants, then updates to the control to get the functionality we need, only when the MyBase.Onwhatever call returns.
Oh! And there is also a limit to the number of Timers supported per-process and system-wide.
-- modified at 12:27 Tuesday 15th May, 2007
|
|
|
|
|
I didn't say put the UI thread to sleep. I suggested calling a procedure asyncronosly. This procedure would work on a seperate thread. To be clear this is what I had in mind.
1) The focus event fires
2) In that event we call another procedure asyncronosly
-This allows the normal cursor placement to finish
3) The procedure we called fires and highlights everything in the textbox
Putting the [i]secondary[/i] thread to sleep for a split second was just a precaution to make sure the select all fired late enough. I know your far more knowledable then I and I may be missing the problems this method creates. Even if they would be rare. But thats how I did it and the method seemed to work. I suggested a timer as a secondary option to pull off the delay. In this case putting the thread to sleep obviosly wouldn't be needed and certainly not desired. It was just an alternative thought, not really what I was suggesting.
As you've already made clear it probably is best to create a custom control.
|
|
|
|
|
TwoFaced wrote: I didn't say put the UI thread to sleep. I suggested calling a procedure asyncronosly. This procedure would work on a seperate thread.
This would work, PROVIDED the thread that your thread was waiting for completed its work in the time alloted. If the system is under load, it's entirely possible this won't happen.
TwoFaced wrote: -This allows the normal cursor placement to finish
It assumes that the process completes. It has no way of knowing it.
|
|
|
|
|
friend..
try this out.. this is a VB code, so look out if you can do it in your platform...
Private Sub Text1_GotFocus()
SendKeys "+{END}"
If Text1.SelLength = 0 Then
SendKeys "{END}"
SendKeys "+{HOME}"
End If
End Sub
Private Sub Text1_Click()
Call Text1_GotFocus
End Sub
do reply if its working in .NET
-- modified at 1:45 Wednesday 16th May, 2007
|
|
|
|
|
Why it is said that Delegates are type-safe Function Pointers?
can somebody explain?
|
|
|
|
|
Because the act in a similar way to function pointers do in languages such as C and C++, but in a type safe way. In otherwords, the compiler will complain if you point to a method where the signature doesn't match the delegate.
|
|
|
|
|
Private Sub WriteToDebug()
Debug.WriteLine( "Delegate Wrote To Debug Window" )
End Sub
Dim del As MyDelSubdel = New MyDelSub(AddressOf WriteToDebug)
del.Invoke()
isn't above code is exagerated?
isn't that the following code line is sufficient
call WriteToDebug
|
|
|
|
|
Nilish wrote: isn't above code is exagerated?
If by exagerated you mean "contrived" then yes. It is written like that to show how it works. Not as an example of why you would use it.
Nilish wrote: isn't that the following code line is sufficient
call WriteToDebug
But can you pass the address of the method around in code with that construct? That is the real power of delegates. When an event is raised it uses delegates to call to the event handlers. The code Microsoft wrote knows nothing about your code, so this is a good option for passing the details of the event handler to the windows control. (For example)
|
|
|
|
|
Colin Angus Mackay wrote: But can you pass the address of the method around in code with that construct? That is the real power of delegates.
I admit , what u said
but
isn't that good to accomplish something in less lines of code.
i meant
first i am declaring the delegate
then i am providing the reference of the function.
then i am invoking it.
so three steps
on the other hand just one line of code
call functionname()
|
|
|
|
|
Nilish wrote: so three steps
on the other hand just one line of code
call functionname()
The point of a delegate is that you do separate the process in several steps.
Consider this scenario:
Person A has written a class that person B will use.
Person A has declared a delegate in the code.
Person B provides the reference for the delegate.
Person A has written code that uses the delegate, without needing to know at the time what it will be referencing.
---
single minded; short sighted; long gone;
|
|
|
|
|
Nilish wrote: isn't that good to accomplish something in less lines of code.
We're in the VB forum... and you want to do things with less code.
Nilish wrote: first i am declaring the delegate
then i am providing the reference of the function.
then i am invoking it.
so three steps
on the other hand just one line of code
call functionname()
Well, since delegates are used heavily in event handlers, you might like to work out how many lines of code the equivalent would take without the existance of delegates. Then you will see where you are saving lines of code.
The example shown earlier is, as I've said, contrived to show you how delegates work. It is NOT an example of where or why you would use one, as I've also said before.
|
|
|
|
|
Hello,
VS 2005
Passing data using events between child and parent is not difficult. But how would you handle a event from another form that didn't create instance of that form.
For example. form1, form2, form3.
form1 open form2.
form2 open form3.
How can you handle an event in form1 which has been raised in form3? The 2 are independent of each other, as form1 doesn't have an object for form3.
I have a button on form3 that when pressed should pass some data to form1.
Thanks
|
|
|
|
|
Add 1 module
'Write This line
Public Module Globals
Public Form1Ref as Form
End Module
In the constructor of form1, write
FormRef=Me
Access FormRef from Form3
|
|
|
|
|
steve_rm wrote: How can you handle an event in form1 which has been raised in form3?
You can't. Form1 doesn't even know that an instance of Form3 exists. Form2 would have to subscribe to and handle the event comming from Form3, then, in response to this event, raise an event of it's own that Form1 would have to subscribe to.
|
|
|
|
|
hi,
i get the following error:
The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
How it can be resolved.
Thanks,
SD
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
