SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

Mantis - Squeak Packages
Viewing Issue Advanced Details
6824 OmniBrowser tweak always 12-22-07 00:13 04-09-11 20:10
0006824: OBConfirmationRequest uses a poor default for saying no.

in a fresh sq3.10-7159dev07.12.1

In a workspace evaluate:
OBConfirmationRequest prompt: 'phui'

(You will get the box pictured in phui.gif)

The problem is that both the cancel choice and the cancel button both say cancel.

The less prominent choice returns false as it should.
The more prominent button returns nil.

Which leads to a debug box asking for a truth value.

There is a design choice here.

Either the big cancel button should return a default of false instead of nil.
This makes the box always return a truth. But loses a distinction where the user refuses to choose.*

Or the default choice should appear as something other than cancel. (Something like No would be good.)

Yours in curiosity and ser vice, --Jerome Peace

*Hmmm what would happen is someone deleted the box w/o answering?
related to 0006684closed mikevdg Squeak No way of specifying okLabel and cancelLabel in UIManager>>confirm: 
related to 0006848closed GazzaGuru Squeak Packages UIEnhancements does not handle UIManager>>confirm:trueChoice:falseChoice: 
 phui.gif [^] (2,794 bytes) 12-22-07 00:13
 phui2.png [^] (1,226 bytes) 01-09-08 14:07

12-22-07 01:03   
Ha. I don't have edit privledges here.

This issue is related to 0001231
Resize window (eg workspace) makes scrollbar size and placement very incorrect
01-09-08 14:07   
Interesting, I only get a box with an ok and a cancel choice, but without a cancel button (see appended image phui2.png).
So for me this works as it should.
Damien Cassou   
01-09-08 14:12   
I don't see the relation with 0001231!
Damien Cassou   
01-09-08 14:28   
David, it's because you don't have UIEnhancements loaded.
01-09-08 14:30   
aha, okay, I see.
But then this bug is not related to OmniBrowser I guess?
Damien Cassou   
01-09-08 14:31   
This problem is visible when UIEnhancements is loaded. This package changes how things are displayed. The bug is in fact in ToolBuilder which does not allow confirmation requests with specific yes/no labels. Thus, the code for the confirmation dialog in OB used #chooseFrom:values:title: instead of a real confirmation dialog.
Damien Cassou   
01-09-08 14:32   
We should wait for ToolBuilder to provide a confirmation dialog with specified yes/no labels.
Damien Cassou   
01-09-08 14:36   
David, in fact it is because when ToolBuilder provides a correct message (something like #confirmYesLabel:NoLabel:), OB will have to use it. So, I let this bug open to remind us to fix this when ToolBuilder is ready.
Damien Cassou   
01-10-08 07:43   
The method UIManager>>confirm:trueChoice:falseChoice: is now implemented. I recommend to wait a bit before using it (until this is added to universe and UIEnhancements implement it too).