xsharp.eu

The autorecover feature is only intended to save your last changes in the case VS crashes. You can check this by yourself: Make a change in your source code, and after the defined save time you will find a ~AutoRecover.XXX.prg in %LocalAppData%MicrosoftVisualStudioBackupFiles<Your solution>. If you kill VS now (use the task manager ) and start VS again, it offers you the recovery.
The recover file is deleted when VS closes regulary, so it is useless for backup purposes.

gerd

Hi Dick,

So how is this supposed to be done?
Example: when I would add a pushbutton on a Windows Form and double click on it, VS creates the event somewhere (seems random) in the .prg or .cs (etc) file. Now that will be in the same file as were the generated code is created, being the same file where Kees lost his hand programmed code.

Normally, even with Windows Forms, I'm using my own control and window classes, and my pushbutton class has a OnClick method, that searches for a method with the same name in its owner, and when found, it calls it.
And my painted window classes have a name that starts with an underscore, and all the written code is in a subclass.
That works very well (in fact, I'm using that for at least 20 years now in VO), and it makes it much, much easier to navigate in my code as I have completely separated prg files between painted and written code.
In VO, I have very long modules with a lot of entities, but this is hard to manage in prg files, so I have splitted up X# code in much more and much, much smaller files, keeping nearly a class per file. And fortunately XIDE permits folders in projects (like VS does), and that makes is much easier to organize all the prg files.
Wolfgang

I tested autorecover. It works for c# and it seems that it doesn't work for x# files. But all it does is save modified files after 5 minutes. When the file is saved, the backup get's deleted automatically. This helps when VS crashes, but not in this situation, when a save deletes code.

There are two VS Addins, that might help, but I didn't test them:
* https://marketplace.visualstudio.com/it ... .VSHistory (saves a copy every time you save)
* https://marketplace.visualstudio.com/it ... toSaveFile (this might work in combination with the windows file history)

Guys,
I will make a change to the code generation in the Windows Forms editor, and I will copy the old code to a .BAK file when generating code.
That should at least help when you detect a problem immediately.
I am not sure if we can intercept the AutoRecovery mechanism. I am not sure if that is documented and available to us.
Robert

Hi Robert,
maybe someone (Fabrice?) could write a plugin for Visual Studio that does regular autosaves of all project files, like XIDE does and VO AutoExport does for VO.
Using GitHub is not a replacement for such a feature, unfortunately.
And such a plugin could be make X# more popular to VS users.....
Wolfgang

Hi all,

When Dick described the steps that led to the loss of the code, I remembered a similar case several versions of X# back. I was learning how to write Windows Forms applications in X#. I created a test form with several controls. When I double clicked on one of the buttons, the button click event method was generated, but it was placed inside another method. That is, the code has been corrupted. I could not repeat the situation and noted for myself that apparently the interaction of X# with Windows Forms is still raw. Since I do not have real applications with Windows Forms on X# (only porting from VO with VO forms), this did not bother me much.

But now Dick described a similar situation, where again the cause of the problem was the generation of the button click event method. Perhaps the X# development team should take a close look at this place. Something is wrong with it.

Best regards,
Leonid

robert wrote:Guys,
I will make a change to the code generation in the Windows Forms editor, and I will copy the old code to a .BAK file when generating code.
That should at least help when you detect a problem immediately.
Robert

Thank you very much, that would be a big help indeed. In all cases so far I immediately knew something was wrong after saving a window, mostly because of the strange compilation errors when code has been corrupted. A .bak file would have saved the day last Friday. Also, if it happens again and I have a .bak file I can send both in so you can compare and possibly find out what the problem is.

Something I noticed today which is similar.
I normally move all my own Windows Forms related code to a separate prg.
Today I was making a change to a simple form with a webbrowser control on it where I didn't separate the code.
Yesterday I'd added a DocumentNavigated event with 3 lines of code.
Today realised I needed DocumentCompleted instead.
I edited the prg and commented out my lines of code in the DocumentNavigated event leaving the METHOD and RETURN lines untouched.
Then opened the form editor and opened the events panel in properties.
Deleted the entry for the DocumentNavigated event, double clicked on DocumentCompleted.
As expected, VS put me back to the code file with an empty DocumentCompleted event,
BUT my DocumentNavigated event code was gone completely.
I'd expected that still to be there, just no longer tied into the form.

Hi Leigh,

Can you please try this sequence again, can you reproduce the problem for a second time?
Because I tried here a few times and I never get the previous code to be deleted. Maybe it could be because I am using a newer VS integration version though (to be released soon) and it might be one of the problems that Robert has fixed.

.

Tried it again the other way around and yes it deleted the DocumentCompleted method and replaced with the blank DocumentNavigated method.

So sequence was:
Open the code-behind prg
Comment out the lines in the event method
Save the changes
Leave the code page open
Open the form
Click the browser control and go to event properties page
Delete the event name next to DocumentCompleted
Double-click on event for DocumentNavigated
VS puts me back on the code-behind page with an empty DocumentNavigated method and no DocumentCompleted method.