WAD Reload File From Disk

[CityguyUSA]

This was crazy. I don't even want to put it together. So for some reason the debugger didn't go to the Exit command. At first I thought well maybe it looks at it like a label but exit can set a value and I was sure I had seen it be the current statement before. But all the debugger commands except stop and pause (which I've never been able to get to work) were grayed out. Of coures it is an IF statement. Just to be sure that it went there I added the /B to the Exit but it wasn't exiting to the OS. The green bar is where it stopped.


Anyway I changed the source:

I changed the code and reloaded from disk.

Except it didn't reload. No Exit /B.

So I re-opened it from disk.

And still no update.

Since I can only post 5 images I chose to ignore the 1 where I made the update in Notepad++ and saved it but I have it.

 

[rconn]

A "Reload from Disk" discards all of the changes you have made, unless you save them first. This is WAD.

Reload from Disk is intended to be used if you've made a number of edits and decide you want to revert to the original version.

 

[CityguyUSA]

Jesus do you pay attention?

 

[CityguyUSA]

Do you get your pay docked for every bug and just change them all to WAD?

 

[vefatica]

Just curious: How else (other than as than Rex said) might "reload from disk" work?

 

[CityguyUSA]

Reload from disk = load the source from the last time you saved it to disk shouldn't matter what product you saved it to disk from that's irrellevent. In fact your debugger is designed to detect changes to source from outside the READ ONLY debugger so it can ask you if you want to reload it. You think it's reloading it from a special place? The caveat being if the debugger is active then none of that works because it locks the source. You can't save it from anywhere outside the debugger unless you press that stop button in the debugger. Rather odd from a READ ONLY debugger to lock the source.

I've just documented to you that it's not doing that in fact I even showed you that re-opening the script didn't reload anything and now you want to tell me that reload from disk means something else (it doesn't). I'm telling you by the many problems I've identified and documented that very few things are WAD unless that design is not to work yet you want to keep blowing smoke up my a** and treating me like I'm stupid by answering problems by twisting my words into something I didn't say so you can tag it WAD. It is a WAD and not a very good one but the only one. I just didn't realize or didn't get to trial it enough to figure that out.

Since day 1 I was told that I shouldn't be making changes in the debugger that I could cause problems by doing that and now that it suits you to say the opposite you're implying that people make changes to the source and save them in the debugger. Either way Reload from disk means find the source at the location you loaded the current source and pull a fresh copy. It doesn't mean I made some changes in the debugger that I don't want to save so back them out. The only place it can back them out too is the last saved source on the disk unless you have an Undo system in place.

If you don't want to improve this product then don't offer support. It's a waste of my time documentintg this stuff only to have you tag it WAD and like I said several tickets back I'm spending more time debugging your debugger than I am my script I don't think that's how a commercial product should function.

 

[MGibs]

I did some experimenting with BDebugger (which I assume works the same as CMDebug).

At the risk of making this situation worse, I'm going to offer some observations and try to bring down the temperature on this thread.


When you open a file in the Debugger, the source file can be edited in the debugger and you can make and save changes to the source file.

When you start a debugging session by clicking on the start button,

any unsaved changes you made in the debugger are saved to disk and the source file becomes read-only, within the debugger.

When you are in an active debugging session, the toolbar changes. The start button turns gray, and the stop button becomes red.

In this mode, the source file in the debugger will not be editable. If I changed the source file outside of the debugger and saved it to disk, it did save the changes, and I got a pop-up message telling me the file has been updated and asking if I want to reload it. When I selected Yes, the debugger beeped at me twice and didn't load the changed file.

If I then selected Reload from Disk, the debugger did load the modified file from Disk, but the debugger appeared to get confused on the line numbers (I had added lines) and was stopping on some blank lines, etc. (@rconn - I'm not sure if reloading should be allowed in an Active debugging session.)



In a separate test, if I did the same steps and ignored the pop-up message, then when I clicked the Step Into button the debugger disabled the Step Into, Step Over, and Run To Breakpoint buttons.

If I tried to select Reload from Disk, the debugger beeped at me twice and refused to load the file from disk.


Looking at the screenshots in the prior posts, I can see that the Stop button is red indicating that the actions described were all attempted in an active debugging session. As Rex has described elsewhere, updating the source file, even outside the debugger, while in an active debugging session can (will?) lead to some unpredictable results depending on the changes made.

It would seem that best practice would be to (a) stick to editing the file in the debugger when not actively debugging, or (b) make changes outside of the debugger when not actively debugging, and then Reload from Disk.

 

[rconn]

Reload from Disk should not be done in an active debugging session, as it is guaranteed to screw up the debugger by changing the insertion pointer, breakpoint locations, etc.

A Reload will always retrieve the file as it is on the disk; it cannot do anything else. If you have changed the file in the editor and not saved your changes, a reload will overwrite your changes. If you did save the changes, a reload will result in exactly the same file contents being (re)loaded into the editor.

 

[vefatica]

Does starting debugging save the file to disk? I think @MGibs said it did.

 

[rconn]

Does starting debugging save the file to disk? I think @MGibs said it did.

Yes, if it has been modified since you loaded it.

 

[Charles Dye]

Waiting for DWIM Reload, which reloads what you meant to save to disk.

 

[vefatica]

Yes, if it has been modified since you loaded it.

That's only useful if you don't debug it.

 

[rconn]

That's only useful if you don't debug it.

??? I don't understand your point. It is useful IF you debug it; otherwise it wouldn't work with .BAT and .CMD files, which close and reopen the file for every line. If the file wasn't saved, the debugger would be running a different version of the batch file than what you're looking at on the screen.

 

[vefatica]

I was thinking of the debugger using a temp file for editing/debugging, updating the original on demand or at exit (with a prompt). Is that well thought-out?

 

[rconn]

I was thinking of the debugger using a temp file for editing/debugging, updating the original on demand or at exit (with a prompt). Is that well thought-out?

I can't imagine how that would be possible without prohibiting CALL's or self-modifying BAT or CMD files.

 

[CityguyUSA]

I did some experimenting with BDebugger (which I assume works the same as CMDebug).

At the risk of making this situation worse, I'm going to offer some observations and try to bring down the temperature on this thread.


When you open a file in the Debugger, the source file can be edited in the debugger and you can make and save changes to the source file.

When you start a debugging session by clicking on the start button,

View attachment 5916

any unsaved changes you made in the debugger are saved to disk and the source file becomes read-only, within the debugger.

When you are in an active debugging session, the toolbar changes. The start button turns gray, and the stop button becomes red.

View attachment 5917

In this mode, the source file in the debugger will not be editable. If I changed the source file outside of the debugger and saved it to disk, it did save the changes, and I got a pop-up message telling me the file has been updated and asking if I want to reload it. When I selected Yes, the debugger beeped at me twice and didn't load the changed file.

If I then selected Reload from Disk, the debugger did load the modified file from Disk, but the debugger appeared to get confused on the line numbers (I had added lines) and was stopping on some blank lines, etc. (@rconn - I'm not sure if reloading should be allowed in an Active debugging session.)



In a separate test, if I did the same steps and ignored the pop-up message, then when I clicked the Step Into button the debugger disabled the Step Into, Step Over, and Run To Breakpoint buttons.

View attachment 5918

If I tried to select Reload from Disk, the debugger beeped at me twice and refused to load the file from disk.


Looking at the screenshots in the prior posts, I can see that the Stop button is red indicating that the actions described were all attempted in an active debugging session. As Rex has described elsewhere, updating the source file, even outside the debugger, while in an active debugging session can (will?) lead to some unpredictable results depending on the changes made.

It would seem that best practice would be to (a) stick to editing the file in the debugger when not actively debugging, or (b) make changes outside of the debugger when not actively debugging, and then Reload from Disk.

if only it worked. These are not the conversationss I had with anyone. But sure in a real IDE the I stands for interactive. Like I was said I was told not to make changes that's why it was READ ONLY. I why I made my changes in an external editor which was working fine up till this event. If I don't edit anything in the IDE there's nothing but what I saved from my editor to load. Reload from disk means load from disk the last things saved to disk.

I find it curious that you have a different experience in the IDE than I do. I never clicked on Step-into and had step-over or run to breakpoint made inaccessible that's a whole new problem.

 

[Charles Dye]

I can't imagine how that would be possible without prohibiting CALL's or self-modifying BAT or CMD files.

Setting aside the depravity of self-modifying batch files, it's not unusual for a batch to use its own name and/or path to find related files.

 

[vefatica]

I can't imagine how that would be possible without prohibiting CALL's or self-modifying BAT or CMD files.

I get it (also @Charles Dye's comment). I guess "Reload from disk" has to be only modestly useful.

 

[CityguyUSA]

A Reload will always retrieve the file as it is on the disk; it cannot do anything else.

And yet that's what started this post.

 

[MGibs]

I never clicked on Step-into and had step-over or run to breakpoint made inaccessible that's a whole new problem

Your screen shots above seem to show the same state I got to. Specifically, that you are in an active debug session (Red Stop button) and the StepInto/StepOver/RunToBreakpoint buttons are all disabled.

You may not have followed the exact same steps to get there...but your screen shots seem to show that you got there.

The only way I was able to mess things up like that was when I was editing or reloading the source file while in an active debugging session started with the Start button.

I was told not to make changes that's why it was READ ONLY. I why I made my changes in an external editor which was working fine up till this event.

I think that what happens in the debugger when you are editing the source file during a debugging session may depend on the specific changes being made.



As I mentioned above, I think the key takeaway is to only edit the source file (or Load from Disk) when not in an active debugging session. Your screen shots seem to imply that you were attempting to Reload Load from Disk and Reopen the source file while in an active debugging session.

If you have issues when not updating during an active debugging session, then providing specific steps to recreate the issue gives Rex a fighting chance at addressing them.

 

[CityguyUSA]

Your screen shots above seem to show the same state I got to. Specifically, that you are in an active debug session (Red Stop button) and the StepInto/StepOver/RunToBreakpoint buttons are all disabled.

You may not have followed the exact same steps to get there...but your screen shots seem to show that you got there.

The only way I was able to mess things up like that was when I was editing or reloading the source file while in an active debugging session started with the Start button.




I think that what happens in the debugger when you are editing the source file during a debugging session may depend on the specific changes being made.



As I mentioned above, I think the key takeaway is to only edit the source file (or Load from Disk) when not in an active debugging session. Your screen shots seem to imply that you were attempting to Reload Load from Disk and Reopen the source file while in an active debugging session.

If you have issues when not updating during an active debugging session, then providing specific steps to recreate the issue gives Rex a fighting chance at addressing them.

I've never attempted to reload during and active debug session. Not even sure it would let me because I've never tried it. But you know what I can't do during an acitve debug session - not that didn't already say this - I can't save my edit from Notepad++ because the READ ONLY debugger locks up the file. So why then would I attempt to reload it from disk?

 

[CityguyUSA]

Your screen shots above seem to show the same state I got to. Specifically, that you are in an active debug session (Red Stop button) and the StepInto/StepOver/RunToBreakpoint buttons are all disabled.

So the problem I was reporting was that the debugger had ended and it hadn't executed the exit. That's why you see what you see. Does it seem right? No. It wasn't attempting to do anything it was just sitting doing nothing.

 

[CityguyUSA]

The only way I was able to mess things up like that was when I was editing or reloading the source file while in an active debugging session started with the Start button.

I get it (also @Charles Dye's comment). I guess "Reload from disk" has to be only modestly useful.

The only time it's useful is when you have a script loaded that you want to pick up the most recently saved version whether that includes updates or not.

 

[CityguyUSA]

I think that what happens in the debugger when you are editing the source file during a debugging session may depend on the specific changes being made.

No that's not at all what happens. If you're editing in a external editor you can edit whatever you want but if the debugger is active you cannot save those updates becuase the READ ONLY debugger locks the source.

 

[CityguyUSA]

Reload from Disk should not be done in an active debugging session, as it is guaranteed to screw up the debugger by changing the insertion pointer, breakpoint locations, etc.

A Reload will always retrieve the file as it is on the disk; it cannot do anything else. If you have changed the file in the editor and not saved your changes, a reload will overwrite your changes. If you did save the changes, a reload will result in exactly the same file contents being (re)loaded into the editor.

I haven't done it but what should happen if you reload from disk during and active debug session is it should reload and reset the entire session. I tried it because I was sure it wouldn't even be an option but it is. So you can reload it. The new question becomes does it know it hasn't changed and that's why it let's you think it reloads it? Or in my case just doesn't reload it and pretends it does?

 

[CityguyUSA]

Is this product original to jpSoft or was this purchased? If it was written by jpSoft or someone working there is that person still around or have they left? This may explain some of the confusion regarding functionality.

 

[CityguyUSA]

A "Reload from Disk" discards all of the changes you have made, unless you save them first. This is WAD.

Reload from Disk is intended to be used if you've made a number of edits and decide you want to revert to the original version.

Our is it there to make it easy to load your changes that you've been making in Notepad++ so you didn't have to traverse the open file dialog? Hint: Which are you going to do more often? Make updates that you want to test or screw up updates and want to revert?

 

[CityguyUSA]

Does starting debugging save the file to disk? I think @MGibs said it did.

What reason would you save to disk a file you just opened?

 

[rconn]

Our is it there to make it easy to load your changes that you've been making in Notepad++ so you didn't have to traverse the open file dialog? Hint: Which are you going to do more often? Make updates that you want to test or screw up updates and want to revert?

You are editing the file in Notepad++ while it is also open in the debugger editor, and then you debug it? That workflow is definitely not supported in the debugger. It will cause multiple problems, including trashing your bookmarks, breakpoints, and watch list, which are loaded when the file loads in the debugger, not when / if the debugger detects that someone else has modified the file.

Breakpoints (and bookmarks) are saved as annotations in the file by the debugger editor. There is no provision for this if you're using an external editor. If you are determined to use Notepad++ as your editor (not sure why, because Notepad++ and the debugger editor use the same Scintilla internal editor) you should not start the debugger until you have finished your edits, and then close the debugger before you make any new changes in Notepad++.

 

[Charles Dye]

Breakpoints (and bookmarks) are saved as annotations in the file by the debugger editor....

Including, perhaps, character 0x001F (Unit Separator)?