When creating a method, right after entering the Method Name, if one presses Tab, the caret shortly shows in Parameters, then jumps into the code area on the left.
I cannot count the number of times it made me enter the parameters in the code area.
It would be a lot more logical to go
Method Name → Parameters → Return Type → Code
It may very well be a bug since the caret jumps, but in case that behavior was intended by design, I file that as a feature request. It would help gain productivity.
It’s a bug, and we have several reports already.
Many users, myself included, have griped about this since Xojo was released. Apparently, it’s hard to fix.
I wish this was “just change the tab order”
It’s not 
Suspected so from the caret jumping over.
[quote=144737:@Norman Palardy]I wish this was “just change the tab order”
It’s not :([/quote]
Guess it is not. I am sure you will get to the bottom of it eventually 
As an alternative, you can enter the parameters right in the method name. Type something like “method(param as type” and press return. (Closing paren not needed.)
Great tip. Thank you.
Actually courtesy of @Jeremy Cowgar .
Let him be thanked
Yeah there’s a bug there too
You SHOULD be able to write the entire signature method name params & return type & have it all split up correctly
Thats not working correctly at the moment
If you need a regular expression to do it… 
I’ll just use the compilers parser so it matches what the compiler expects
I know what the grammar looks like & it’d make a pretty ugly regex as its far more complex than I suspect anyone would guess.
Challenge accepted!
(?x)
^
([a-z][^\\s()]*) \\x20*
(?(?=\\() \\( ([^)\\r\
]*)\\)? \\x20*)
(?(?=as) as\\x20+(\\S+))
$Method name in group 1
Params, if any in group 2 (requires trim)
“As” in group 3
If there is only a method name, there will only be one subgroup. If there is no trailing “as”, there will only be two subgroups. I tested this against these cases:
method
method(s as integer
method(s as integer)
method ( s as integer )
method (s as integer ) as string
method ( s as)as something
method()as string
method as string
method()AHA, the batle of the GIANTS! 
I run a little helper app alongside Xojo and one of the things it does is add a hotkey for just this case. After typing the method name I press Command-period instead of tab and the helper plays some mouse clicks so that focus ends in the parameters field Other hotkeys can close the bottom pane. Just can’t work with those mousing interruptions and forget they aren’t fixed yet.
[quote=144803:@Norman Palardy]Yeah there’s a bug there too
You SHOULD be able to write the entire signature method name params & return type & have it all split up correctly
Thats not working correctly at the moment :([/quote]
Bug report has already been filed for this <https://xojo.com/issue/27717>
[quote=144826:@Kem Tekinay]Challenge accepted!
[/quote]
Nice but quite incomplete
Really
extends, byref, arrays, paramarray, public, private, sub, function, optional
And you can combine them in a LOT of weird & wonderful ways
ANY signature you can dream up thats legal - and thats a huge range far beyond this regex
I appreciate the attempt but this is why I said
[quote=144819:@Norman Palardy]
I know what the grammar looks like & it’d make a pretty ugly regex as its far more complex than I suspect anyone would guess.[/quote]
Except I’m not trying to validate a signature.
Perhaps I’m defining the problem incorrectly. I see it this way:
There are three fields. The user enters data into the first that may be meant for all three. This pattern picks out the parts that belong in the other fields without attempting any form of validation. Once the original string has been split, validation can take place on the individuals parts.
But perhaps this scheme does not fit in with how the data is handled internally. At any rate, that’s why things like optional and byref could be included by the pattern without attempting to see if they are being used properly. The pattern doesn’t care what’s between the parens.
The user may enter data that is meant for ANY of the items on that editor including params, scope, return type
Now I’d tend to agree that we may not need / want to check the specific syntax in the params field we do need to make sure that you use the generalized form somewhat correctly
public sub( params) as type
should not be the same as
sub public(params) as type
Do people type Public/Private into that field in your experience? The pattern could certainly account for those if so. Otherwise, anything not matched would be rejected outright. At least, that’s how I’d do it.
(As a purely academic discussion at this point.)