TOPIC:

First let me emphasize that I think that a lot is (being) done in X# and that the support given is second to none. Nevertheless, I am still doing most of my work in VO. We have assigned a few projects to be converted for which we think it is more important that these can be maintained in .Net, e.g. for better acces to features and maybe even more important: a better chance that we find programmers in the future than for VO code. I expect that for some project keeping these in VO is fine. Working in VO is still a lot easier but with some added features in X#/VS the difference could be reduced. What I would like to know, there's no rush for reply, is an appx ETA for the following X# wishlist. Probably in a future Road Path? (most of the below points aren't currently mentioned there although sometimes they pop up in replies here).

I sorted by what we think is most important.
[EDIT] I've added a new point 10 which I think you can't realize but the priority would be much higher than 10 for me.

1 VS Immediate window working with X# code. What I read in www.xsharp.eu/forum/public-vfp/3130-how-...le-in-debugger#23495 seems a promising part!
2 Correct casing for all keywords (so it can be used in the Immediate Window too)
3 Option to open constructor, class (and probably preinit/postinit) like in VO. Ideal would be a choice for Goto Definition and Peek Definition in some way
4 Support for Codelens
5 Auto indent for structures like in VO. Earlier you wrote that you did not want to align ENDIF with IF because a user could be typing ENDIFme which then aligns unwatned. Apart from the fact that I question how many times a user types ENDIFme against the number of times a user has to manually align ENDIF (or press <Enter> + 2x <Backspace> every time, I wonder if 'ENDIFme support' is so important for other users, can it not become a setting?
6 Edit & continue support
(I guess this is difficult see www.xsharp.eu/forum/public-chit-chat/158...-and-step-back#11610)
7 Remembering variables (e.g. just added, or in use in the current method) so they pop up in the suggestion list like it works in VO
8 Option to open the click method in a Winforms form also when the code does not reside in the code behind prg but in a separate program
9 What would be very handy is a way to better deal with comments. We often place comments with a number of tabs outlined on the same column but this is quite some work to keep it aligns on editing and readability varies (better in 4K monitors). Not sure if there are better ways to do this but maybe you have a suggestion?
10 Search result do not include the name of method or function. I assume that is one of the many VS shortcomings which you can't fix but it is one of the worse shortcomings of VS.

I would welcome comments from others, e.g. to learn which of my wishlist items others find important.

Dick

Dick,

Some quick answers to your questions:

1) "Debugger Immediate window" We are working on this. This requires an expression evaluator that understands X#.

2) "Keyword case" I am not sure what you mean with this. Did you enable the Keyword Case Synchronization in the Text Editor settings ? Is that not enough?

3) "Peek and Goto definition". This should work again in 2.13.2. At this moment only a single item is supported.
Multiple items would require us to create a tool window with a list that you can choose from. That is more work and not to be expected in the near future

4) "CodeLens" This is a LOT of work. Unfortunately most/all of the CodeLens in C#/VB is hardcoded for these languages. So we will have to recreate all of that.
And what exactly are you thinking of: references, source code control information, something else ?
The only thing that the editor provides is a mechanism to show information on a certain line in the editor.
All the information on that line has to be provided by others (us)

5) "Formatting" This should mostly with with 2.13.2. At this moment formatting is done when you type Enter, not while typing other characters

6) "Edit and continue" Difficult. I will discuss this with Nikos in Germany.

7) "Auto Type" This auto type feature was working in an internal build, but not perfect. We have disabled this for now but will try to complete this asap.
The problem that we have is that the list of possible words to show in the completion list is MUCH bigger than in VO, since the .Net Framework
has a LOT more types, members etc. Most likely we will try to limit the list to parameters, local variables and fields in the current type.
That should not cost too much time. And maybe after an AS keyword we can list types and namespaces. But if you have a long list of USINGS at the
start of your program then this list may already get fairly long.

8 ) "Open Click method" This works for code in the form.prg. To open code outside form.prg and form.designer.prg we have to make the Windows Forms editor smarter than it is.
This is also not working in C#.

9) "Better deal with comments": I have no idea what you mean with this

10) "method and function in Search" Do you mean the name of the method or function where the text is found ?
That will be difficult, since the search mechanism is completely handled by VS.
They work file based, so the search returns a filename and line number.
There seems to be a way to influence the search mechanism, but I have not had the time to look at this yet.
And I am not really sure if it is work the time spent


Robert

Hello Robert,

Thanks for the extensive reply. Some answers:

1+2 If the current keyword casing is what the IM window expects, it's fine. But as most of my IM Window entries end in an error I thought they didn't. It's a lot less important when 1) is working.

3+4+6 It's a pity that these are hard and time consuming to program, as it would make the disadvantage VS versus VO smaller. It is what it is.

5 The extra <Enter> after endif while it indents without at the else remains illogic to me. It's not a main concern but just a returning nuisance reminding me multiple times a day how much more usable VO is. compared to VS. Maybe that is why it works that way

8 This is certainly not a main thing; I added it because you earlier wrote that you may be able to fix it. Which would be kind of cool as Microsoft couldn't.

9 Currently we add comments aligned at the right of the code. This is quite time consuming to maintain because we keep aligning it; I noticed that even going through the code with the cursor made casing change and disrupted the alignment of comments despite using tabs. I do not directly have a clear alternative but I was wondering if others may have some ideas. It would be probably best if comments could be detached from the actual code. It don't expect you to be able to change this as it is VS after all, but you never know.

10 Yes, I mean the method name. E.g. I am searching something and I would recognize the method I am looking for. But now I have to open sometimes many of the search results (same with compiler errors) before I finally found my code. I fully understand that this is probably unsolvable for you. But I wonder how programmers can work reasonably in VS if no solutions are sought for such shortcomings (of MS, not yours!)?

Dick

Dick,

1) The intermediate window understands expressions and not commands. So what is the deal with keywords there ?
9) If you have enabled keyword case synchronization then going through the code with the cursor could indeed change the casing. But that should not disturb the comment location, unless you are using a proportional font

Robert

Hello Robert,

robert wrote:

1) The intermediate window understands expressions and not commands. So what is the deal with keywords there ?

I remember from earlier attempts that if I e.g. typed something like : ? Substr(cVar,5,1) that I had to vary the capitalization of Substr multiple times until the case sensitive C# IM window finally understood it. With thanks to the Microsoft idiot who thought it was a good idea to make C# case sensitive.

robert wrote:

9) If you have enabled keyword case synchronization then going through the code with the cursor could indeed change the casing. But that should not disturb the comment location, unless you are using a proportional font

I don't remember ever changing the VS font (Ebrima 10) and indeed it's proportional. I think I have to try Consolas which I use in VO.

Dick

robert wrote:

They work file based, so the search returns a filename and line number.
There seems to be a way to influence the search mechanism, but I have not had the time to look at this yet.
And I am not really sure if it is work the time spent
Robert

How can you say "not sure worth the time spent"? In most of my .prg files there are dozens of methods, functions etc. If I search for something I get a long list of lines and line numbers, giving me no clue at all which method, function etc. each line concerns. How can anyone work in this way? What am I supposed to do, put every method, function etc. in a separate .prg file?

Dick,
I would recommend the font "Hack" which has a clear distinction between zero and uppercase,
as well as between the 1 and the lower case L


sourcefoundry.org/hack/

Robert

Kees

KeesIC2 wrote:

robert wrote:

They work file based, so the search returns a filename and line number.
There seems to be a way to influence the search mechanism, but I have not had the time to look at this yet.
And I am not really sure if it is work the time spent
Robert

How can you say "not sure worth the time spent"? In most of my .prg files there are dozens of methods, functions etc. If I search for something I get a long list of lines and line numbers, giving me no clue at all which method, function etc. each line concerns. How can anyone work in this way? What am I supposed to do, put every method, function etc. in a separate .prg file?

You are the first of our customers that asks for this feature.
Also nobody replied to Dick's message by saying: yes I miss that too.
Apparently this is no issue for others.
Maybe they have a different way of organizing their source code ?
We have limited resources, and we try to spend the time on features/issues that affects the most people.

Robert

Hi Kees and Dick,

about the 10), related to Search, I must admit I don't understand where is the trouble, so I'm afraid that we might be talking about something different.

I often search for string or method names, etc...
What I do is Ctrl-F, then type my search, and in the search dialog, press the combo sign next to Arrow that follow the search text.
From there, I select "Find All".
This produce a tab at the bottom of my VS called "Find" and the text I was searching; and a list of lines where the text is found, grouped by Files (in bold); and for each line I have the the position (line/col). A simple double click will jump at the right place.
And If this is not ok I can re-open that window to select another location...
Is this what you are looking for ??

Regards,
Fab

ic2 wrote:

...But I wonder how programmers can work reasonably in VS ...

They don't, they use Xide <s,cr>

Fabrice wrote:

Is this what you are looking for ??

Yes, you are describing the very rudimentary search option which is all there seems to be. The source file in bold AND in a separate column, repeated for each line. How efficient! In the column one would expect to see the method or function concerned, unfortunately VS or X# is not smart enough to determine that. I find it impossible to work like that, but since Dick and I are the only ones to have a problem with it, we must be doing something wrong. So I ask everyone: if you search for something and you are particularly interested in only a few methods, but your .prg contains let's say 100 methods, what would be the best way to do this?

Now i don't get you, too. I see in Fab's screenshot BELOW each "bold" line the found entities listed?

Hi Karl,
we XIDE users are a minority even between X# users (but IMHO XIDE is a beast in productivity).
Wolfgang

Robert, Fabrice,

I think Dick/Kees are referring to showing in the search results, in columns, what is the name of the enclosing class/entity etc of each hit. Also myself I cannot imagine me working without this feature, but unfortunately this is not how VS works, its find results window(s) only display plain text per entry, with only filename and line content shown. This not only lacks crucial information, but is also very difficult to read. Not at all your fault of course, it's just how it is.

Hello Karl,

FFF wrote:

Now i don't get you, too. I see in Fab's screenshot BELOW each "bold" line the found entities listed?

Yes, in Fabrice's screenshot it seems to work a we want it because he searches for VOID. As this is on the end of each (void) method we do see the method names.

But this is when you search for something else:



Now we have 18 ShowLongError results in 1 .prg, in probably about 10 methods. If I would see the name of the method, instead of a useless line number, I could, often at least, directly see which one I was really searching for. Now I have to open up 'til 10 methods before I know that.

Also recently I searched for something for which I wanted to know if it was used in methods or functions. There were over 100 hits. In VS I have to open them one by one and count. Very, very time wasting.

Is it now more clear why we find this so poor?

Dick

Hi Dick,
ok I think I got you :thumbsup:
So here, MS won't be of any help I think.
To achieve that, it we would have to write an extension, rewriting a kind of Search, and at the same time use the internal Items DB, to give you a more precise localisation information.

Fab

Hello Fabrice,

Fabrice wrote:

ok I think I got you
So here, MS won't be of any help I think.
To achieve that, it we would have to write an extension, rewriting a kind of Search, and at the same time use the internal Items DB, to give you a more precise localisation information.

Good I could make it clear finally. What I would like to hear from you:

1 Do you agree that method/function info missing can actually be a major burden? Kees, Frank and I wonder why this isn't raised as a major shortcoming (unless others know something that works that we don't know)
2 Is there any chance (as far as you can say now) that this can be created in a reasonable time?

That MS won't be of any help is nothing new

We are, I would nearly say, desperately, seeking ways to gain productivity/time, close the gap a bit more between VO & VS so we can justify continuing with X# conversions. We do realize that there are other advantages but for multiple of our products the time loss weighs heavier...

Dick

Hi Dick,

It's just because different people have different needs, different ways of working and preferences. Also for myself, the lack of this feature and many other VS related things would be totally a showstopper for my work, but the fact is that NOONE else here (apart from you guys and me ) has complained about this/those. Different people like and can cope with different things, it's amazing to see how different we all are!

Hello Chris,

Some people also tend to think "it's new so it must be better", and the longer you would work in VS and not in VO, the more used you get to work with a mainly crippled environment. Plus that most people would think that the X# team can't fix it and I always think the opposite

There are things in my wishlist which I can imagine would differ in importance for some, but anyone with a seriously sized project must have had this situations at least once in a while as I showed in the picture and described with the 100+ entries I really had to open one by one and count manually. While in VO I can even save the search results containing all info.

Without WPF in some of our projects we would likely have used Xide already.

Dick

Hi Dick,
again: you can write WPF applications with XIDE, and I'm pretty sure that the code to build a form is much cleaner and easier to read and to maintain than the XAML horror.
That is the main part of code that builds a form:

and this is a part of the form:

This a project I'm working on now - entirely using XIDE and code built windows.
Wolfgang
Wolfgang