Your understanding of the meaning is same as mine. If it's true then user of Workspace must declare variable, and by same token if the radio button is not selected then it is expected that they should declare the variable. So your version below makes sense. On 06 Jun 2011, at 10:03 PM, Stéphane Ducasse wrote: Thanks carlo now reading the code this is even more confusing..
mustDeclareVariables
to me measn that you should declare var :) so the correct version is mustDeclareVariableWording ^ mustDeclareVariables ifTrue: ['<no> Automatically create variable declaration' translated] ifFalse: ['<yes> Automatically create variable declaration' translated] but I may be wrong. Stef On Jun 6, 2011, at 9:24 PM, Carlo wrote:
Hi
As far as I can see the behavior is correct. If you declare the variables as you have
|persons aPerson|
then they won't be bound to the Workspace. If you do not declare them then these variables should be bound to the Workspace. You can bring up the Workspace menu and select 'Inspect variables' to see what is bound.
I did notice though that there is a boolean logic bug compared to squeak 4.1 in Workspace>>mustDeclareVariableWording
^ mustDeclareVariables not ifTrue: ['<yes> Automatically create variable declaration' translated] ifFalse: ['<no> Automatically create variable declaration' translated]
The 'not' is missing from Pharo1.3 whereas it should be there. This only affects the display logic which may confuse users to which mode they are in.
What do you mean? Because we should have the **same** working (not <>) in both branches since the info is displayed as a radio button. if the radio button is on, it creates variable definiton, if this is off = no it says it is off (to the creation of variable and not their non creation) :) So I guess that my proposal is correct but let us know. Stef
Carlo
On 06 Jun 2011, at 5:16 PM, Stéphane Ducasse wrote:
Hi miguel
this is probably linked to the way the workspace keeps its binding to declare variable. Can you check in 1.3 because we will release it soon.
Stef
On Jun 6, 2011, at 4:09 PM, Miguel Sanchez wrote:
Hi All,
I'm not sure if this is a bug or a feature or PEBKAC error.
I have strange behaviour In Pharo one click 1.1.1 and 1.2.1, when I open a Shout Workspace and enter the following: ===============================================
"Person is a dirty little class that maps from a DB table and a horrible complete creation method."
|persons aPerson|
aPerson := Person personId: '32055' personTypeId: '1' nationalId: 'I00735' firstName: 'ANA ROSA' surname: 'XXX YYY ZZZ' title: 'Ms' birthday: ('01/01/1970' asDate) language: 'ES ' gender: 'F' maritalStatus: 'M' nationality: 'ES' countryOfResidence: 'IT' activity: 'CN-O' regDate: '17/06/2009 00:00:00' vatRegNo: '1234'.
persons := Set new.
persons add: aPerson.
persons add: 3. ===============================================
If I ctrl-d each statement individually. after the final line. persons is a set with the two elements I have just added.
If I open a fresh shout workspace, copy and paste the code, select all, and ctrl-d all the text, then I get persons = nil. afterwards.
I've debugged and both methods execute in the same way.
So like I said, bug, feature or PEBKAC?
Thanks,
Miguel