Community
Participate
Working Groups
3.8. 1. start a new workspace 2. paste this into the Package Explorer: ---%<--- public static void main(String[] args) { int count= 100; for (int i = 0; i < count; i++) { System.out.println(i); } } ---%<--- 3. launch it ==> Console view opens and shows output but does not scroll. It scrolls for all future launches. If the Console view gets closed, the problem surfaces again.
Using a delay in org.eclipse.ui.internal.console.ConsoleManager.showConsoleView(IConsole) seems wrong to me. Replacing #schedule(long) with #schedule() fixes the problem. Sarika, please verify the proposed fix. Also check whether there was a special reason to use the delay.
The delay was added as a fix to Bug 130431
(In reply to Sarika Sinha from comment #2) > The delay was added as a fix to Bug 130431 OK, it looks like #showConsoleView is called many times, not just when necessary to show it. Sarika, we should try to treat the case where the console isn't visible/active yet from the other case.
I tried breaking showConsoleView method in two parts where consoleFound can be done first and if required we can do the update on console with a delay if required. To find if console is there or not we use IWorkbenchWindow window = PlatformUI.getWorkbench().getActiveWorkbenchWindow(); This works only in a UI thread otherwise it returns null. The getActiveWorkbenchWindow method is specially made to behave like that. And breaking this into two separate threads does not appeal as it can be source of other threading issues.
(In reply to Sarika Sinha from comment #4) > I tried breaking showConsoleView method in two parts where consoleFound can > be done first and if required we can do the update on console with a delay > if required. > > To find if console is there or not we use > IWorkbenchWindow window = > PlatformUI.getWorkbench().getActiveWorkbenchWindow(); > > This works only in a UI thread otherwise it returns null. The > getActiveWorkbenchWindow method is specially made to behave like that. You could try to find another way to know whether a Console is already open, e.g. remember sate in the console manager. > And breaking this into two separate threads does not appeal as it can be > source of other threading issues. I agree. I'm also fine deferring that bug if we can't find a simple solution.
Created attachment 252129 [details] No auto scroll lock for terminated process Added a Check for terminated Console to disable Auto scroll lock feature
(In reply to Sarika Sinha from comment #6) > Created attachment 252129 [details] [diff] > No auto scroll lock for terminated process > > Added a Check for terminated Console to disable Auto scroll lock feature I assume this patch is for bug 459494.
Deferring it for now!!
I can't reproduce it anymore with 4.6.3 and 4.8 head. Could be a side effect of the fix for bug 484329.
