bugGNUstep - Bugs: bug #42230, Calling setState: on a button from...

 
 

You are not allowed to post comments on this tracker with your current authentification level.

bug #42230: Calling setState: on a button from the action method of another button doesn't work...

Submitted by:  Gregory John Casamento <gcasa>
Submitted on:  Mon Apr 28 23:19:54 2014  
 
Category: Gui/AppKitSeverity: 3 - Normal
Item Group: BugStatus: Confirmed
Privacy: PublicAssigned to: Fred Kiefer <FredKiefer>
Open/Closed: Open

Fri May 2 13:36:54 2014, comment #2:

German is correct, the best way here is to use this NSMatrix method. Only then will you get the correct behaviour when you switch your matrix to radio mode.

For your specific problem it would be sufficient if either NSActionCell or NSButtonCell would override the method setState: with the usual block of code added:

if (_control_view)
{
if ([_control_view isKindOfClass: [NSControl class]])
{
[(NSControl*)_control_view updateCell: self];
}
}

That way the control, in this case the matrix, would redisplay the changed button. But this hasn't been documented by Apple and would not help with the radio behaviour. I am almost sure that the old Next code could achieve this behaviour without this special method, but I haven't any clue on how to do this.

Fred Kiefer <FredKiefer>
Project MemberIn charge of this item.
Thu May 1 05:58:44 2014, comment #1:

Could be this a problem with the matrix? The matrix can attempt to handle the state of their buttons. If I add an outlet to the matrix and then use:

[matrix setState: NSOnState atRow: 1 column: 0];

Instead a call to the button, it works.

Germán Arias <espectador>
Mon Apr 28 23:19:54 2014, original submission:

Use case: A gui with two buttons. One button has an action method which calls setState: on the other button with the value NSOnState.

Procedure:
1) Run the application attached.
2) click the button

RESULT: None of the radio buttons in the matrix are highlighted.
EXPECTED: The second button from the top should be highlighted.

Procedure 2:
1) Load in the debugger
2) set a break point in buttonhit: method.
3) run the application attached in the debugger
4) hit the button, it should stop at the breakpoint
5) continue in the debugger console.

RESULT: The radio button which should have been highlighted in the previous case is now highlighted.
EXPECTED: This is what was expected, except it should have happened in the first case without the debugger breakpoint.

Does this issue indicate a race condition of some sort? Given that GUI is single threaded I'm not sure what's going on here.

Gregory John Casamento <gcasa>
Project Administrator

 

Attached Files
file #31269:  ButtonTest.tgz added by gcasa (6kB - application/x-compressed-tar)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by FredKiefer (Posted a comment)
  • -unavailable- added by espectador (Posted a comment)
  • -unavailable- added by gcasa (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri May 2 13:36:54 2014FredKieferStatusNone=>Confirmed
      Assigned toNone=>FredKiefer
    Mon Apr 28 23:19:54 2014gcasaAttached File-=>Added ButtonTest.tgz, #31269

    Back to the top


    Powered by Savane 3.1-cleanup