Easy. You've already found out that TSQL and Access's version of it are not the same. Access only supports a subset of TSQL and adds it's own "flavor" to some of what would be considered normal for other implementations of SQL.
If you wanted to support different database engines, you'd have to implement different data layers in your application to support them.
For instance, SQL Server supports batch queries, where Access does not. You'd have to implement the missing functionality in your own code instead of relying on the database engine to do it for you.
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.
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 eventfor our control so the form can
' handle the event if it wants to.
' Then do what we really want it to do, AFTER the base TextBox does
' what it needs to.
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
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.
' Drop the key by not passing it to the base class. Pass Handled back up the chain.
e.Handled = True
' GotFocus isforwhen the user tabs into the TextBox
Protected Overrides Sub OnGotFocus(ByVal e As System.EventArgs)
' Let the base TextBox do it's thing first.
' Then we'll select all the text.
' If the user clicks anywhere in the TextBox, select all the text in it.
Protected Overrides Sub OnClick(ByVal e As System.EventArgs)
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.
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.
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.
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.
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.
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.
isn't that the following code line is sufficient
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)
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
isn't that good to accomplish something in less lines of code.
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