Ok, so where errors are in quite clear now but if you click the button and errors are found in a section not currently visible you may think the code it fine.
I really think another dialog isn't the answer but it would be good to communicate in some way that x issues where found
Could you give any specific example? It would help illustrate the issue.
Take a sample program
# A micro:bit Firefly.
# By Nicholas H.Tollervey. Released to the public domain.
import radio
import random
from microbit import display, Image, button_a, sleep
# Create the "flash" animation frames. Can you work out how it's done?
flash = [Image().invert()*(i/9) for i in range(9, -1, -1)]
# The radio won't work unless it's switched on.
radio.on()
# Event loop.
while True:
# Button A sends a "flash" message.
if button_a.was_pressed():
radio.send('flash') # a-ha
# Read any incoming messages.
incoming = radio.receive()
if incoming == 'flash':
# If there's an incoming "flash" message display
# the firefly flash animation after a random short
# pause.
sleep(random.randint(50, 350))
display.show(flash, delay=100, wait=False)
# Randomly re-broadcast the flash message after a
# slight delay.
if random.randint(0, 9) == 0:
sleep(500)
radio.send('flash') # a-ha
Load it into Mu. Now the code area scrolls because the length of the script. Press the check button:

All looks fine doesn't it?
However if I scroll down to the bottom i see:
(the warning in this case being a lack of newline)
My point is when clicking the button it isn't clear whether or not issues where detected.
Thanks, I see now what you mean. There is very little feedback from the button press to emphasise the checks have been carried out, and you are right, if the markers are outside the current text view then it is not clear if something has been found.
I'm sure there must be a way to scroll to a specific line, let me see what I can find.
Would something like this be too abrupt?

Aparently SCI_LINESCROLL hasn't been implemented in the PyQt bindings, so a scroll animation would have to be done manually.
How about something as simple as just turning the button red? (It returns to normal when you click it and there are no problems.)
I think a combination of both would be good.
How about something as simple as just turning the button red? (It returns to normal when you click it and there are no problems.)
Perhaps some visual feedback on the button would be sufficient, but I'm not 100% sure about the click behaviour approach. So let me see if I understood:
I think that could work, but it feels like we are have having this different behaviour just for this button and I am not confident it's all that intuitive. We have other buttons that "toggle something" when pressed, should we perhaps follow that pattern?
Maybe we could have the Check button toggle "the checker being activated" with some type of green/red feedback, but that would require some type of real time checking to be processed. Maybe run the checker periodically in the background or if code hasn't been edited for an amount of time? Just bouncing ideas.
true it could give it an appearance of a toggle button. Maybe animate the button content in some way?
Click button -> shows a magnifying glass or working symbol
Warnings found -> show red cross possibly with a badge indicating how many
No Warnings found -> briefly show a green tick before returning to standard state
Btw, I had a very rough test of a scrolling effect on the check in case this is something we might still want to explore:

Nice. How about having the button in two states? Thumbs up for checks pass and thumbs down (see attached) for failed checks...

that combined with the scroll effect would be great
+1
Yes, I think having these two things would make it quite clear. To be completely honest though, the red thumbs down feels a bit dismissive, maybe a red exclamation point instead?
We also need to agree on the button behaviour, would the button toggle the checker On/Off, or would the button run the checker and update the icon and markers on every click?
Upon reflection, I guess we should just ensure the first error message is in view.
Seems simplest, how messages are presented has changed as well so should be clearer
Most helpful comment
Upon reflection, I guess we should just ensure the first error message is in view.