Bug 330023 - Step commands are enabled even if the command won't be executed
Summary: Step commands are enabled even if the command won't be executed
Status: ASSIGNED
Alias: None
Product: CDT
Classification: Tools
Component: cdt-debug-dsf (show other bugs)
Version: 8.0   Edit
Hardware: PC Windows 7
: P3 minor (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-11 12:04 EST by Dobrin Alexiev CLA
Modified: 2020-09-04 15:20 EDT (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Dobrin Alexiev CLA 2010-11-11 12:04:39 EST 
Build Identifier: 3.6.1

I noticed that if I increase the interval if the user preference “Run/Debug  -> View Performance > Minimal interval between steps” to 2 seconds the step buttons are enabled but the command won’t be dispatched to the user within two seconds.
I believe in the DSF version the step commands enablement has to somehow be hooked up to the SteppingController. 
Not a big dial. 


Reproducible: Always

Steps to Reproduce:
change the profernce  “Run/Debug  -> View Performance > Minimal interval between steps” to 2 seconds.
Start a DSF GDB debug session and step more than once. 
See the buttons are enabled but clcking them does nothig.
Comment 1 Anton Leherbauer CLA 2010-11-16 04:09:07 EST 
We cannot disable the step commands because there is no event that would make them enable again.  We also don't want to actually queue a step command during the delay time, because when you hold down the F5/F6 key you want stepping to cease as soon as you release the key, esp. with long delay times like 2 sec.
I understand that the behavior of the toolbar buttons is a little unexpected, but there is no easy fix for that atm.