Thanks for the newest version of the compiler - I have it downloaded and now installed. I am testing it out on the research and test app I am creating - related to the session material for Cologne 16 - 19 2018.
First of all the app did not a first compile with the new version - even though it had been with the old (previous) compiler. Eventually, I found that by changing a VO flag it got me able to compile. I attach a image or two to show what I got and needed to correct.
Since I started the small WPF app from the start - a new template etc., I have no idea why the VO flags were an issue, as I've never used them while doing my WPF work in the last 12 months.
I will keep an eye on things over the next few days / weeks.
Oh! - sorry, but I also ought to report that with the new 1.1 compiler in VS Prof. 2015, I now get some editor window lock-ups on quite a regular basis. Not really disastrous but quite annoying for any serious work I should think. I can't quite work out why they are happening, but they certainly weren't there previously.
Hope this helps, and THANKS for all the TEAM effort.
So the "Treat missing types as USUAL" option was enabled before and you disabled it now? If that's so, I think the older compiler versions were ignoring this option, but now the compiler properly checks it. Probably this was enabled in the project by accident (or old template?), it shouldn't bother you any more.
About the editor lock ups, can you please zip and post a solution which has that problem? Please also include info about in which prg you see the lockups, in doing what (simply typing, invoking intellisense etc).
Also as an experiment, please go to Options/Text Editor/XSharp and in the Tabs page set Indenting to None. Then in Intellisense page set Keyword Sync to Nonw. Do the above make a difference on this problem?
Thanks for the response, yes, you are/were right about the USUAL stuff - I never touched anything previously.
I did have to change the flag from TRUE, it was the only flag set at TRUE.
I will see what happens after I try what you say in VS.
As a guess it seems to me that the long 'pause' of short lock-ups happen when I change the editor mode from run tot edit - just by clicking in the editor surface.
I will go and see what I can learn.
Oh! by the way, I have made and run a few trial X# samples on Generic classes, so I may solve my Type issues the Generic way. Still interested in anything you can say about my questions on Type related issues however.
Okay, sorry for being vague and not using very expressive (good) words.
I have just been getting my Generic class to work for the wrapper to go around System.Array class and so I am now much more familiar with where the time delays (freezes) happen.
I have the editor open for the X# class I am working on.
I then save the changes and run the compiler to get an app execution.
After the running of my app it completes and I then try to place my cursor somewhere slightly different in the X~ code - to edit or add more code. This is where it seems to regularly happen. I made all the changes you suggested in the Tools sub menus but it seemed to stay the same.
Does this help or do you wish me to make a short screen capture video to show you?
I am running a very small app, and although it is from the WPF template I am not actually using the XAML / WPF parts - just adding small test code classes and methods to the Initializing method.
It was doing okay before the new download/install.
Let me know if I can do anything else to help.
Now then, time for bed I feel. had enough success for one night with my Generics and the user defined array index limits ;-0)
Please create a new simple WPF project, build it and run it, do you see the same problem in the editor? If yes, then we need to understand exactly what the delay is, as I can't reproduce it here. If you are not seeing the problem with the new small WPF project, can you please zip and send me the original project that does show this problem?
And it would appear that in my new solution/project (template WPF) I get the same behaviour in the editor, but only when I have put a bunch of code lines (including commented lines) into the same PRG file - this is open in the editor.
I seem to get it when I compile and run the code, then after completeion of execution I try to use the editor and reposition my cursor, and quite often it is when the cursor is in the commented green code.
For your interest I have had something strange happen in the editor window - probably a total of six times today / yesterday - check the image to see a scrambled image with spurious content over my code lines :-
The blue part should not be shown - it is content of the Output (or similar) window showing in my editor window. If I move a tab back then forward it goes away, or clears itself.
Sorry I can't be more help - but keep on asking if it may help things.
I have had a good think about my issues and I have decided to try going back to version 1.02 with 1.03 upgrade.
Now I have this re-installed I will see if I go back to how things were before the weekend. If I see (with the same application in the editor etc.) that operation 'things' return to the way they were, then surely it must look as if something 'odd' has been introduced ?
I will do my best to keep you informed of anything which looks as if it will be helpful.
On the zip side of things I will do as you ask in the morning ;-0)
I have just been working on my research and test app and have a 'wrapper' class for a 2D .NET System.Array which allows both row and column index value ranges to be virtually anything, and unlimited. This is what I will zip up for you.
Here is some sample test code and results, in case anyone is interested. I will release the Generic code later.
Now then, on the issue of me reverting to version 1.02 and update 1.03, this has been done and now I have tested it for about an hour while developing. There were no issues at all - AND - all the responsiveness has returned to the X# editor - I am getting much more work done now.
I was sorry to be the bringer of 'doom' in reporting this possible issue, but if its not right then its not right. In the sort of words of Don - you know, he used to say "its done when its done!".
Absolutely no problem for reporting a problem, on the contrary! Of course we want to know about all existing problems, so we can fix them! So yes, please send me the zipped solution when you get a chance, it will greatly help to find and fix this.
Thanks for the file! Just a bit more info please, you said that the editor is locking up often, so after just clicking with the mouse in a few places this happens to you? Or do you need to be also typing code to see that? Which .prg file can you reproduce that with?
I do believe you that you are seeing this, as the guys did fix many issues with editor slow downs, but now I don't seem to be able to reproduce such a problem anymore. Just need to find out what you are doing when you get this problem..
The short term freezes or lock-ups tend to happen when I move my cursor in the editor with a mouse click. Often (but not always) when I enter a comments area.
As I said, it is difficult to get a 100% method/process to make this happen every time - BUT - try doing a compile and run, and then after completion click the cursor somewhere, once then another place etc. This is the best I can do. But now I have returned to 1.02/1.03 the VS editor seems to skip along quite nicely.
For your interest I now have discovered this error message - I think it was there with the app when I was using 1.1 version.
Good luck in finding the freezes - the cursor seems to disappear or show as an 'i' beam, and then after nothing showing of the cursor I get the blue round circle for a few seconds.