I´d like to know how can I stop execution in smalltalk. I entered an infinite loop and don´t want to loose the code that´s written. I tried using pause button but doesn´t seem to be right.
Normally, even if you are unable to stop execution, you should be able to get the code changes you made back from the .changes file. If you can restart the image, there is a 'recover lost changes' menu entry. Always first make a backup copy of the changes and image files before trying this. (In Pharo/Squeak. Other smalltalk have similar possibilities)
it depends on the dialect and possibly keyboard settings.
try CMD-. or CTRL-., which works in most dialects.
Related
I hope I can explain my specific annoyance clearly enough:
Quite some time ago, IntelliJ introduced a feature in the run console to parse the content of the output and would try to print a nice tree structure on the left. However, its default behavior of jumping to the error was very annoying. To illustrate my point:
When it starts normally, the full console output is available in the right panel. However, when things happen, or, in my case of gradle run, when I simply stop it, IntelliJ would jump to the specific block of output only with the error:
Note, in the second screenshot, that there is no scroll bar on the right side of the right panel, and thus I cannot scroll up to view the actual run logs. I have to click the left panel's top element in the tree to be able to view all logs.
The locking to a specific block of output is nice to have, but I am happy without it too, as before it was introduced. But the default jumping to that block is annoying and irritating. Almost in all cases I started and ended a run like this, I have to click the left panel to view the whole log -- this "Build cancelled" error block is of no use at all. And when it's jumping to an actual exception, majority of the time I'd need to look around its context for the cause, which requires me to re-orient myself in the log flow where the block was at. This is very counter productive for me.
I have been assuming IntelliJ should provide an option to either not jump to the error by default (leaving the full log available in the right panel), or to disable the whole console output parsing as a whole.
I have not been able to locate a setting for either of this. Does anyone know if that's possible?
We are working to fix that. Please vote and follow https://youtrack.jetbrains.com/issue/IDEA-241844
first, I cannot attach my vi files, sorry. I'm not allowed, but I can attach snippets.
I've got a vi that opens and executes functions from a script file, and I'd like to be able to continuously click a button to reload the script file without having to restart the program. Currently the script file commands sit outside my main while loop and and uses a case statement to put the system in idle mode (manual control) when the button is not depressed before launching the program, or if it is, it will instantly open a dialog box looking for a script file upon program launch. I'd like to be able to open a script file numerous times during the execution of my program, but don't fully understand how, and this may be my own misunderstanding of what's going on with the code if I move it inside the main while loop. how is this best accomplished?
If you put your code outside of the loop, it is only executed once (very important: "dataflow"). You need to put the code into a loop to execute it multiple times.
You can insert the vi-snippet into your vi by drag&drop.
My vi contains two different options. You can change the vi as you need it, my vi is incomplete. I inserted a simple 2D-Array because I'm not sure if the vi you use after building the path is selfmade or given by LabVIEW.
For both options you should let the code run in some kind of state machine and use an Event Structure (I think you already implemented your program this way since you wrote about a main loop).
Version 1:
Everytime you click the button, the event is triggered and the code inside the event structure is executed.
Version 2:
Here you set a boolean if the button is pressed and handle the event with that value.
Since you wrote that you already have a main while loop, this option might be better four you. The first loop would be your main-loop, second one would be the loop in Version 2. You just need to add another case for the script to be loaded in.
VI:
I hope this is helpful for your problem.
Feel free to ask if you need more help or if you have any questions :)
when i launch the commit dialog (thg commit), the focus is on the commit message. this is probably the most common place it should be. in my case, i typically want to review the files i have changed and make sure i'm committing what i think i'm committing and not anything i don't intend. the only way i have found to get to the file list to be able to use ctrl+d to view visual diffs is to use the mouse. tabbing doesn't work because in the commit message input control, it just creates tab characters.
is there a way to use the keyboard and avoid the mouse altogether to move the focus to the list of files?
thanks for any help you can offer.
I've had a quick skim through the source, and also had a look at the wiki, and it seems there's no quick "official" way to do it.
One way I have found, which involves a lot of tabbing, is the following sequence:
$ thg commit
and when the window comes up, do CTRL+F, which puts you into the "Regular Expression Search" box. Then press TAB a lot of times (10 when I just tried it, but it will vary), until you get into the file selection box. Not great, but it sort of works... I do wonder if reaching for the mouse may be quicker, tho' :)
I am trying to develop a little macro for PowerPoint using VBA. However, the "Development Environment" is an absolute nightmare!
The worst: there seems to be no real good way to generate debug output! I read that the Debug.Print output is supposed to go to the Immediate Window, but nothing appears there! So I am currently using MsgBox to generate debug messages. :-(
What's also really bad is, that errors in a macro always crash PPT. So one has to wait, until it is gone and then one has to restart it again and get rid of all the Recovery attempts. This always takes ages!
If I set On Error Resume Next it doesn't crash - at least not as often - but then things just silently don't work and I can't see what and why things go wrong (unless I plaster the code with MsgBox calls, but that requires 100'000 clicks during each execution).
And running the code in the debugger and single stepping trough the code doesn't work, either, since my macro refers to the current "ActivePresentation" and that doesn't seem to exist unless one starts the slideshow mode. So this debugging is driving me nuts!
Is this really the only possibility or environment to develop VBA code in? At least some idea re. debug output, anyone?
M.
The worst: there seems to be no real good way to generate debug output! I read that the Debug.Print output is supposed to go to the Immediate Window, but nothing appears there!
At the risk of sounding insulting (which I don't intend!) do you have the Immediate window open? While in the IDE, press Ctrl+G to see if anything new appears. If so, that's the Immediate window.
What's also really bad is, that errors in a macro always crash PPT.
Not ordinarily, no. It can happen that way, of course; your code might be triggering a bug in PPT. Heaven knows, I ran into enough of that in PPT 2002 and 2007. If you're using reasonable error handling and still running into errors that crash PPT, stepping through the code as it runs should allow you at least to narrow it down to the line or two that cause the crash.
And running the code in the debugger and single stepping trough the code doesn't work, either, since my macro refers to the current "ActivePresentation" and that doesn't seem to exist unless one starts the slideshow mode.
Again, no. The ActivePresentation refers to whatever presentation has focus in the app, whether it's in slide show or any other view. If your code's in one presentation and its' supposed to be acting on another, that can cause some confusion, but you simply need to switch to normal view, make sure the presentation you want to access is visible (I'd make sure not to have several in view) then Alt+F11 to return to the IDE and run your code.
All of these suggestions apply to any Windows version of PPT, going back to Office 97 (Mac? Thinks different. If you're using a Mac, mention that. There are a few differences but for the most part, everything above applies except for the Alt+F11).
If none of this seems to help on your setup, it may be time to do a repair of Office.
I have written a program and have used it (in debug mode) multiple times to test it out sometimes adding code and/or changing it. After a while any code I wrote or new buttons or features I added to the form would not appear while debugging. I don't know what circumstances led to this.
The only solution I found was to rewrite my code from scratch, however, the problem came back after a while. I don't know what is going on and I can't move on without starting all over again.
Thanks for all the help.
try rebuilding your entire solution, I believe to do this you must right-click on the project and there should be a menu option that says "rebuild solution". Try that.