I'm trying to undo changes in Memory window:
But CTRL-Z does not work and there's no such menu item too:
Is this function supported?
When doing live debugging, there's not much use of an undo functionality in general. If a thread ends, you can't simply recreate it. If you step over a line, you can't easily go back to the state before. If you close a file handle, you can't easily reopen it.
If you changed memory, when should WinDbg disable the ability to undo that? Once that memory was written to by the process? Or do you want to be able to undo even if the memory was written to after your edit?
To what memory content should be undone then? To the values you entered (i.e. undo the action done by the process) or to the values before you entered them (i.e. undo the edits made by you, including the changes made by the process) or undo only those values which were edited by you and not changed by the process yet?
As you see, implementing an undo functionality in a debugging scenario can become really difficult. IMHO, WinDbg was never designed to have undo functionality.
I would even say people do not use the memory window to edit memory content. Why that?
When you do a debugging session, you want your steps to be recorded so that you yourself or someone else can verify and reproduce your actions. In such a scenario, you use .logopen and log everything you do. Actions done outside the command window will not be recorded and thus break the verification workflow.
What do you do instead? You use one of the display commands (db, dd, dp or similar) to show the memory contents before the edit. You then use an edit command (eb, ed, ...) to change the memory. Whenever you want the old values back, you look at the previous output of the d command and e those values again.
Related
I am plagued by a very strange phenomenon. I tend to write fairly esoteric Powershell modules for stuff I do at work. Often, after running one of these, and the module has ended I will move onto some other tasks, and when I happen to bring up my Powershell console window again, several blank lines (or just blank "space") will have appeared in the buffer. It never appears right away, which is the most confounding part.
Afterwards, the blinking cursor exists at the end of this blank space, and the blank space cannot be "backspaced" (so it's not something inadvertently entering spaces or newlines). It's just there, as part of the buffer. I usually just clear the screen with cls to keep it from annoying me.
I used to just chalk this up to the buggy Windows Powershell 5.1 buffering. However now that I've begun using Powershell 7 (and Windows Terminal), I see that the issue still exists.
Here is a screenshot of a v7 Windows Terminal tab an hour or so after my module finished running:
Sometimes it seems the longer I wait the more blank space has appeared. Here is a screenshot of the same console tab about 20 hours later:
I'm sorry I don't have a better way of explaining this. I realize that without any code or pattern to analyze, that this is a very poor question, by SO standards, but I am just as confused as you are. The only pattern I've noticed is that this only seems to happen after I run my various custom modules. However this accounts for the majority of my Powershell usage, so it might be a red herring.
Usually my modules simply do some processing (talking to computers, AD, etc) and just output some information via Write-Host, and occasionally output a [PSCustomObject], which I always capture in a variable. Even if I was accidentally outputting some blank lines or something to the pipeline, I can't see how that would manifest as blank buffer space that grows over time. I thought maybe I was incorrectly killing async jobs or something and that was somehow causing this, but this happens even in purely synchronous code.
To be clear, in the screenshots above there is no code actually running. That module was the only thing I had run in this particular console tab/session, and it doesn't run any background processes. So I can't understand why the buffer is changing all on its own. In both screenshots, the tab/window is the same size as it was when the module first completed, so it's not just a bunch of spaces in the buffer that are being dynamically resized. And as noted, when the module fist completed there were NO rogue characters in the buffer at all.
One other thing about my usage is that it's all done on a remote VM, accessed through RDP, which I use daily. The only other thing I can think of is that maybe something about the console window being minimized/maximized/resized, the resolution changing, or the login session being connected/reconnected has something to do with it.
Does this sound familiar to anyone? Any ideas for what could be causing this or what I can try to understand the behavior better are much appreciated.
I've confirmed that this actually happens as a direct result of simply "restoring" and "maximizing" the Powershell console window and/or Windows Terminal window. When the issue is "present", doing this will often add another "set" of blank space to the buffer before the cursor. Minimizing seems to have no effect, only going from maximized to "restored" and back to maximized.
I've also confirmed that this has nothing to do with my custom modules. I can replicate the issue by simply opening a fresh, maximized console window/tab, running get-process and then "restoring" and maximizing. It doesn't happen every time though.
It also has nothing to do with my custom profile script, as it happens even on a freshly-imaged computer with no profile.
At this point I'm going back to blaming it on buffer/rendering/window manager implementation bugs in powershell and moving on with my life.
My father can't seem to shutdown his computer, ever, so I'm using Task Scheduler to have it automatically power off every night. Thing is, he also can't seem to save his documents, so I need to make sure every open document has it's changes saved when it shuts down. Is it possible to do this using AutoHotkey, VBA, or with some MS Word feature I'm not aware of?
I'm aware of the AutoRecover feature. But, as I understand it, that just saves a copy in another folder that gets thrown away when the document is opened again. It's not as reliable as a manual save.
Any help on this is appreciated. It physically hurts to watch tech-illiterates abuse their PCs.
New slots are added to a scene sequentially. I have a cleanup free form slot that handles any input that slots higher in the order have not handled. It has to be the last slot to be processed. But when I want to add a new slot it becomes the last slot so it is never processed. There seems to be no facility to reorder the slots to avoid this. Any ideas?
Yeah, this is something that is seriously lacking in the UI right now. (You also can't reorder Intents, and they're handled in order as well.)
The only solution I know of is to use the gactions command line tool to download the project, edit the .yaml file for the scene in question, and then re-upload the project using gactions again.
I'm just going to ask for a really basic question on Matlab which bugs me often when using Matlab.
I sometimes, by accident, delete some chunk of my codes when using Matlab; however, there seems to be no way to undo the deletion or recover those chunks back from my codes.
Is there an undo button or short-cut for deletion of codes?
It's not really a big deal if I cant remember those chunk and write again, but it just seems like a tedious work to do again.
The undo button is on the little toolbar in the top-right corner:
Or you can use Ctrl-Z if you are using the Windows shortcuts.
You could use a source control system (SCM) like git (git-scm.com) to make backups of your code code.
Note: you need to save in between and then add them to your SCM. Or you could do backups automatically with a cron job.
I'm making an image editor (e.g. for drawing pictures and diagrams) for iPhone and Android mobile devices. This question would also apply to anything that involves editing documents e.g. spreadsheets, videos, text files.
When the app starts, the user sees all the documents they've created so far in a gallery and clicking a document opens up the editor. My saving options so far, which work as they do on desktop applications, are: "save" (which is good for saving incremental progress) and "save a copy" (which is good for saving a milestone in the editing phase). When the user exits the app, they see the usual "Save changes? Yes/no/cancel" dialog.
However, this approach doesn't seem great:
I've found it common in tests that users accidentally pick the wrong option when shown the "Save changes? Yes/no/cancel" dialog.
Explaining the difference between "save", and "save a copy" to causal users in particular is tricky and is something where misunderstandings will lead to data loss. I want an option like "save as" as well but this is probably the most confusing save option especially since you don't really want the user to specify a filename on a mobile device.
Are there any better interface models I could consider for handling the saving of complex documents on a mobile device?
Some ideas I've considered are:
When quitting the app, changes are always saved to a new file on exit without prompting. The user can then manually discard the original or the edited copy if they wish
and/or
When "save" is selected from a menu in the editor, the updated document is saved to a new file F and all future "save" actions will overwrite F. This lets the user save their progress as they go without having the option of destroying the original file by accident. The only issue with this is what to do if the user saves, makes some changes and then wants to leave the editor while discarding the changes since the previous save. The only ideas I can think of are to add a prompt when exiting or to add a "discard" changes menu option.
I'm looking for something that is flexible, easy to explain and prevents mistakes.
Edit: Due to the nature of my app (large images, destructive and slow operations), it is impractical for me to offer persistent undo (I know there is some discussion to be had here but it isn't practical here even if we just consider development time). This makes autosaving documents more troublesome. I'm aware this limits my options but I'm not expecting perfection.
When I'm in doubt how to handle such things I start some of the flagship apps and look how they do it.
Let's take Numbers for iPad as example.
If I edit a spreadsheet Numbers never asks me if I want to save, it just saves.
If I make changes I can undo them later because there is a Undo function.
And even if I force quit the app the undo option will be there the next time I launch it.
If I want I can duplicate my spreadsheet, but this option is hidden in the "My Spreadsheets" submenu. It's not visible when you create a spreadsheet.
So I would suggest to implement some undo functionality so you can save without user interaction.
I wonder how you ask the user to save when the application exits anyway. On iOS this should not be possible.
Btw, this is what the iOS Human Interface Guidelines say:
Ask People to Save Only When Necessary
People should have confidence that
their work is always preserved unless
they explicitly cancel or delete it.
If your application helps people
create and edit documents, make sure
that they do not have to take an
explicit save action. iOS apps should
take responsibility for saving
people’s input, both periodically and
when they open a different document or
quit the application.
If the main function of your
application is not content creation,
but you allow people to switch between
viewing information and editing it, it
can make sense to ask them to save
their changes. In this scenario, it
often works well to provide an Edit
button in the view that displays the
information. When people tap the Edit
button, you can replace it with a Save
button and add a Cancel button. The
transformation of the Edit button
helps remind people that they’re in an
editing mode and might need to save
changes, and the Cancel button gives
them the opportunity to exit without
saving their changes.
For iPad, save information that people
enter in a popover (unless they cancel
their work), because they might
dismiss the popover without meaning
to. For more guidelines specific to
using popovers, see “Popover (iPad
Only).”
Your app should automatically save without requiring an explicit action by the user. 99% of tne time this is what the user wants, so why put up an obstacle (a prompt) that inconveniences the user 99% of the time to protect tbem 1% of the time?
If you are really concerned about tnat ladt 1%, save N versions and provide a revert feature. If you had an interface for that which would show what was added or deleted in each version, even better. I bet if you do that and monitor how often it is used you'll be surprised at how rarely people actually use it.