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 28 Apr 2014 11:19:54 PM UTC  
 
Category: Gui/AppKitSeverity: 3 - Normal
Item Group: BugStatus: Confirmed
Privacy: PublicAssigned to: Fred Kiefer <FredKiefer>
Open/Closed: Open

Fri 02 May 2014 01:36:54 PM UTC, 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 01 May 2014 05:58:44 AM UTC, 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 28 Apr 2014 11:19:54 PM UTC, 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 02 May 2014 01:36:54 PM UTCFredKieferStatusNone=>Confirmed
      Assigned toNone=>FredKiefer
    Mon 28 Apr 2014 11:19:54 PM UTCgcasaAttached File-=>Added ButtonTest.tgz, #31269

    Back to the top


    Powered by Savane 3.1-cleanup