TOPIC:

I added a toolbarbutton on a Winforms form and doubleclicked on it.

In C# this would create a click event. This happens in a total random area in the .prg, but that is how VS works.
However, in X# it opens the "code behind" prg but does not create the click event. Is there anything I can do about that?

I also have a small request. If I enter a newline, starting a next method, behind code like this:

then the Return statements indents. That should not happen, it should stay aligned with the Method statement.

Dick

Hi Dick,

I don't see a "ToolbarButton" control in the windows forms toolbox, which control exactly did you add and how?

Hello Chris,


You are right. It is called System.Windows.Forms.Toolstripbutton. I don't know how it's added (I have to ask Kees); there's an existing toolstrip with some buttons and there's a small drop down menu which allows me to add more buttons (or other controls) to it.



It is indeed remarkable that the "indenting return issue" only occurs when I press <Enter> after a click event method as I posted.

Dick

Hi Dick,

Seems to work fine here, can you please create a sample showing the problem?

Hello Chris,

You actually have one. Open the sample I sent this afternoon for the Zipextensions issue, open Functions.prg, move to the last line 102 where it says Return True , move the cursor to the end of the line and press <Enter>

The Return True in the line above also indents there - where it shouldn't.

Dick

Hi Dick,

Oh, I meant about the problem with creating the click event.

About the RETURN, this is as intended, since it is considered an "executable" command, so it gets indented like everything else. On the other hand, if you finish the method with "END METHOD", this should indent below "METHOD"indeed.

.

Hello Chris,

Is there any way to prevent this, like a setting?

I don't need END METHOD. But I want Return statements to align with the METHOD...
I am wasting far to much time during programming to move everything back to where it should be, like the ENDIF (always requiring multiple backspaces).

More than once I start writing my new method in VO. Then at the end I copy it,. all perfectly aligned, in X#.
It would make quite a difference if I needn't do that...

Further I will check if I can modify the sample to show the non created event, and if I can't, to find out why it didn't t work in my life project.

Dick

Hi Dick,

I understand you, I don't like indentation working this way either. But even though you and I don't like it this way, still there are probably 100,000s of other developers (VS users) who do prefer it this way apparently, so we can't say much, but we just need to learn to work this way (well, or decide to develop a custom .Net IDE if someone is crazy enough to do it )

Hello Chris,

But isn't that something which can be set within X#?

In VS in C# (or VO) a return does not indent when I press <Enter>.

I think not it should not indent in X# and I think that could be set to work like that.

Like the endif (which does not indent for the rare, I would say, extremely cases where the users want type a variable starting with endif.

Why can't the user who is so stubborn to use a variable like that not correct the indent instead if the countless times X# users press endif?

I very well realize that you can not influence everything, and sometimes a change is conflicting with some other, equally met, interest but in case of the return and endif I find it highly unlikely that not the vast majority would want it the way I write. And which I would say, could be arranged within X#. Or am I wrong?

Dick

Hi Dick,

It's the way VS is supposed to work, when you hit enter, it aligns the code to the indentation it considers correct. Personally I don't like this at all, but VS works like that and X# is "playing nice" with VS, it is doing things the way VS developers expect them to be done. You could turn indentation completely off, but this way you would have to also manually indent IF and ENDIF...

Guys,
A few remarks:

1) Can you please stop bashing VS, especially since a lot of what you are complaining about is not the fault of VS but the result of our choices (from Fabrice and me).
The indenting inside the editor (both while typing and when choosing Format/Document) is controlled by OUR LanguageService component.

2) Indenting during typing is controlled by the setting in Tools/Options Text Editor/X#/Tabs. If you set the option on this page to "None" then no indenting will happen during typing. If you set it to "Block " then each line will have the same indent as the previous line. These 2 settings are controlled by VS.
These settings disable the indenting while typing done by the X# LanguageService.

If you set the option to "Smart" then the formatting code inside our language service gets activated. This is almost the same code that is run when you choose Format Document from the menu. At least it is driven by the same set of rules.
But since Format Document can take a bit more time, it processes all the lines and can therefore start by the first line in the file to determine the current "context".
The "Format wile typing" tries to change as little as possible for performance reasons.

3) If you have a clear example of where "Smart" is not doing what it is supposed to do then share that with us, together with the settings that you have used.
Remember that if there is an .editorconfig file in the solution tree then the settings in this file may override what's in the Tools/Options Text Editor/X#/Indentation page.
The settings inside .editorconfig are documented here: www.xsharp.eu/help/_editorconfig-files.html

4) Aligning RETURN to the METHOD keyword would only work if RETURN is indeed the last statement in the statement list.
But if your code ends with
Then we cannot automatically align the RETURN statement with the METHOD statement. And believe me, many people use that kind of code.

5) In theory everything is possible in the VS editor. However it is sometimes complicated to do that AND maintain good performance.
We also want to make sure that we have one set of code that works in multiple versions of VS, so we sometimes cannot use
the "latest and greatest" feature in our language service.

That is why WE have chosen to align ENDIF with IF when you press ENTER. We could have monitored the current line of text and
align immediately when you close a keyword such as ENDIF (by typing a space, tab or enter) but we have chosen not to do that.
In the VO Editor we have used a component called CodeMax that took care of all of that. And we had control of everything. So that was much easier.

Robert

Hello Robert,

robert wrote:

1) Can you please stop bashing VS, especially since a lot of what you are complaining about is not the fault of VS but the result of our choices (from Fabrice and me).
...
In the VO Editor we have used a component called CodeMax that took care of all of that. And we had control of everything. So that was much easier.

So still a good reason to bash VS then:)

robert wrote:

4) Aligning RETURN to the METHOD keyword would only work if RETURN is indeed the last statement in the statement list.

But it doesn't. I am not talking about a return within an if/endif. I am truly speaking about the last Return of a method. I start the next method and immediately Return indents to where it should not be.

And there's more. I have e.g.When I press <Enter> after that statement the next local indents instead of remaining aligned with the previous local (which aligns to the margin like the method).

I find this less annoying than having to remove multiple characters (tabs, returns) after an ENDIF, but I would definitely consider it a step forward if I needn't remove indents before <Returns> and Locals.

Dick

Dick,
Did you really read my message ?
- I was not joking when I asked to stop bashing.
- I asked for examples including settings. Your complaint about the indenting after the LOCAL statement does not have that. It also misses context. What is before the LOCAL statement ?
- Aligning the return statement (or whatever the last statement is) with the METHOD keyword is not coded, so it is not going to happen. If you want something that aligns with method then use END METHOD

Robert

Hello Robert,

robert wrote:

- I was not joking when I asked to stop bashing.

If you are so sensitive about what I write about VS...whatever..

robert wrote:

- I asked for examples including settings. Your complaint about the indenting after the LOCAL statement does not have that. It also misses context. What is before the LOCAL statement ?

Another local statement. With smart indent on. EDIT: regardless the INDENT settings (it also happens with all checkboxes unchecked)

I have reinstalled 2.12 and there it doesn't happen. Also the Return doesn't indent when I press <Enter>.

So for me it's solved.

robert wrote:

- Aligning the return statement (or whatever the last statement is) with the METHOD keyword is not coded, so it is not going to happen. If you want something that aligns with method then use END METHOD

I am not particularly looking for something to add which is not needed so it aligns nicely with METHOD/FUNCTION..

EDIT: to make myself more clear:

I wanted Return to remain aligned. With that I mean that Returns need to remain where it is and not indent when I press <Enter> what it does do now and not in 2.12. So you write "is is not coded so it is not going to happen" but to me it looks that it is codes since 2.13 and it is doing something it shouldn't (and didn't).

As it works fine in 2.12 it is solved for me and it partly saves me frustration. If everybody else doesn't care I understand that you are not going to look further into it.

Dick

Hello Chris,

Chris wrote:

Oh, I meant about the problem with creating the click event.
.

I have tried a doubleclick on a pushbutton, both on the "Devteam" test program and on another form of the project I was working on. It worked in both cases. Not sure why it didn't on an earlier occasion. Maybe I can collect more info if it happens again..

One note is that this is how the inserted method (=first 3 lines) looks. Return is 3 tabs inserted, end method 2 and not aligned with "Private".

What I think happens is that it is related to the End Class / End Namespace . But in that case, the first "Private" line should align with End Method I'd say.

Dick

Hi Dick,

Yeah, I've seen this, too, it's not right indeed. I suspect it will not be easy to make it always work as expected with so many different indenting options available, but will log this for Robert to have a look into it.