Method creation tab order FR

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.

feedback://showreport?report_id=36817

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 :frowning:

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 :slight_smile:

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 :slight_smile:

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 :frowning:

If you need a regular expression to do it… :slight_smile:

I’ll just use the compilers parser so it matches what the compiler expects :slight_smile:
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! :slight_smile:

(?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! :smiley:

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 :slight_smile: 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 feedback://showreport?report_id=27717

[quote=144826:@Kem Tekinay]Challenge accepted! :slight_smile:
[/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.)