Show link where the compilation error is while using IntelliJ Goland - intellij-idea

currently I use Goland as IDE, it happens that sometimes when I have a compilation error then in the terminal of the IDE it's displayed the error as a link, when I click on that link it takes me to the exact line where the error is, however this behavior is not consistent, sometimes it works sometimes it doesn't (the link is not displayed and only the error message is printed). So, what should I do to ensure that the link is always showed up?

You need to raise an issue on the official tracker, https://youtrack.jetbrains.com/issues/Go, and provide samples for this.
The functionality is automatic and there are no flags to configure.

Related

Tips for debugging a Global.mpt

Short Question:
How do you debug a large Global.MPT file?
Currently my script crashes when I try to open it from the toolbar. It appears the usual, not very helpful, error message regarding the automation error. When this happens I start the individual components by pressing F5 in the VBA window and at the latest then I find the erroneous line.
Now my code runs as it should but I can't find the error that the compiler* has.
How do you deal with this problem?
*Is it a compiler error?
Found a Solution here.
I didn't know that you can compile the code manually.
It showed that i missed to remove a call for a deleted Sub.

How to stop IntelliJ from jumping to a subcategory in run console

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

Why does my VBA procedure sometimes stop in debug mode?

I have a button click event in an Access form that sometimes opens the VBA editor with the 'On Error...' line highlighted as if it is in debug mode. I can F5 to continue the rest of the procedure and it works fine.
It doesn't happen everytime. It seems random except there seems to be a pattern that it happens on the first click of this button right after the file is opened. Not everytime though.
Any thoughts on this or previous experience with the same thing happening and subsequent solution? What might be causing this? It's a terrible user experience.
Well, before running any code (hold down shift key during startup to prevent any code from running).
Now, ctrl-g (jump to VBA IDE). Now from tools. Choose
debug->Clear all Breakpoints
Like this:
Now, open up any code module - hit enter key to "dirty" the code. Now choose debug->Compile (first menu option). It will say Compile "my app name".
Make sure the code compiles. If it does not, then stray break points can still exist.
Next up, you need to check/change the default behavior for a error.
While STILL in VBA editor/IDE
From menu bar choose tools->options. The default is "Break on Unhandled errors"
If you have break on ALL Errors? Well then code that even assumed to trap or even on-error resume next code it BLOW UP and stop. Often developers will say try for existence in a collection, and we error tap to "mean" the element is not in that list. However, the THIS assumes that the default Error trapping setting was not change.
So, double, and then triple check this setting. You can develop for years, and even have some code ASSUME to error out. But that years of development code assumed the default (break on unhandled Errors. If you have break on all errors, then your are toast, and you find all kinds of breaking of code. (the idea of that option is to LET you debug code with error handling without having to disable errors. And with say on-error resume next, you in effect can't debug parts of code anymore.
Now, if above steps don't fix your issues?
Then the next step is to de-compile your application. This will remove the compiled (binary) part of the application. Once you do this, then you do a full re-compile.
To de-compile, you can't do this from the IDE, and you have to use a FULL qualified path to your existing version of access. Say like this:
"C:\Program Files (x86)\Microsoft Office\Office14\MSACCESS.EXE"
"c:\MyCoolApp\Invoice.accDB" /decompile
Now, when you run above, you REALLY must not let any startup forms or code run. (hold down shift key. Now exit access/application. Now re-launch (and again no code to run on startup).
Now, at this point I high recommend a Compact+ Repair (and AGAIN no startup or code to run). So even on the C+R, you have to hold down shift key.
If you during the decomp, start application, then C+R allow ANY code to run, then you have to start over again at the first decompile step.
Ok, now you done the C+R. Now ctrl-g, and now debug-compile.

How can I read errors and warnings in IntelliJ with a screen reader?

I am using IntelliJ Idea for developing scala and Java programs. I am also a screen reader user.
One of the most useful features that IDEs provide is code linting and displaying error and warnings in your code, along with descriptions. I understand if you are a sighted user, you can just hover your mouse over an erroneous line of code and you get a tooltip with the description.
I haven't been able to figure out how to access this description as a screen reader users. So far, to review errors/warnings I would just build the program and look at the command line output, however this is pretty inefficient compared to just hovering over line of code.
Could someone share a better way of reviewing errors/warnings in IntelliJ using a screen reader? Ideally how to access the error tooltip, or how to access a better UI for reviewing them instead of looking at raw command line output.
I'm not sure about warnings however errors can be accessed in two ways:
Firstly when the caret is moved into a line with error the error text is written into the status bar - the problem with this approach is that for JAB applications screen readers are generally unable to find it, so in case of NVDA object navigation has to be used.
The second way requires your caret to be exactly at the point with error - generally it would be set in the proper place if you've navigated to the line with F2. After that you need to press CTRL+f1 - focus moves to the unnamed pane and the error text is its first descendant so once again you need to employ object navigation. I haven't found any reasonable way to access error texts with JAWS sadly.
Importantly, make sure to turn on screen reader support:
settings (ctrl + alt + S) > appearance and behaviour > Appearance > Support screen readers (requires restart)
Then when your caret is on an error/warning, you can press ctrl + F1 and a dialogue will pop up with the description. Press escape to close it.
If you want to make sure the caret is on an error/warning, use F2 to jump to next error/warning.
As noted by lukaszgo1 in his answer, the description is also printed to status bar, but NVDA cant find it using its normal command, because JAB GUI applications are lacklustre in their implementation of accessibility, however if you want to access the status bar of IntelliJ to read the description you can use an NVDA addon which I developed, that adds a command for reading IntelliJ status bar and fixes list items not being labelled properly.
I actually forgot I asked this until I got an answer recently.
Thanks to lukaszgo1 for his answer.

wxWidgets errors occur after upgrading gDEBugger

all. Today I upgraded my gDEBugger (though I don't think it involves gDEBugger) to the latest version but problem occurs. When I tried to open gDEBugger, an alert window named "wxWidgets Debug Alert" pop-up, reporting that "....\src\common\xpmdecod.cpp(822):assert "i==colors_cnt" failed in wxXPMDecoder::ReadData(). Call stack: [00]wxConsole....balabala....", like follows.
All these words seem just like warnings and didn't affect the following work, however I am wondering why this problem occurs? What's the root cause? I am not familiar with wxWidgets and hopes those guru on it can help me resolve it.
You've got a malformed XPM. As XPMs are typically embedded into the program itself, this is not supposed to happen, look at the XPMs used by gdPerformanceCountersDialog::createAndLoadImageList() to check this.
P.S. Next time you could just press Ctrl+C to copy the message box contents to clipboard as text instead of pasting in an image.