Re: [Repast-developer] Disabling Property Widgets

[Mark R. D. <mdi...@la...>]

Nick Collier wrote:

>On Mon, 2003-03-03 at 09:03, Mark R. Diggory wrote:
>  
>
>>As an example case, say I have a boolean parameter and I use the Boolean 
>>PropertyDescriptor to make the presentation into a checkbox for that 
>>value. Is there any "functionality" in the Boolean 
>>PropertyDescriptor/CheckBoxWidget that disables the user being able to 
>>change the state checkbox if there is no "setter" present in the 
>>SimModel class for that parameter/property?
>>    
>>
>
>Ah. I see you what you mean. For properties that can be represented as
>Strings a read-only property (no setter) is represented as a label. In
>the case of the Boolean property descriptor, if the property is
>read-only, the property value will be displayed in a label ("true" or
>"false"). For the other PropertyDescriptors we are not so lucky(!) as
>they don't have read-only state and can still be changed although there
>is no corresponding set method. This is a bug and should be fixed. I'd
>prefer just displaying a String representation of the property value in
>a label as this is a simple fix. I suppose, though, for things like
>arrays and ArrayLists the default String representation isn't really
>suitable.
>
>Nick
> 
>
It might be a little more work, but setting up a "global" 
enabled/disabled state for each property and setting the PropertyWidget 
to that state (instead of "true") when the simulation is stopped/paused 
would allow the widget itself control the "editablity/presentation" of 
its content. You could then configure the various PropertyWidgets to 
display an appropriate presentation given the state of this global 
boolean property. Then a readonly String or boolean parameter could use 
the label internally in thier JPanel while other Widgets could use other 
displays if wanted. For tables I could alter the cell background to grey 
and disable editing.

This makes the widgets do alittle more complex decision-making, but it 
also make them more flexible and dynamic. I'm probibly biased in my 
opinion of this right now, becuase I've been creating the table widget 
and could use such functionality. I also think using the JComponent 
enabled/disabled state is ideal for capturing something like 
presence/absence of a setter method because it leaves the state upto the 
parent and presentation upto the Widget.

I'm not in a rush to get this in place, I'd rather see it well thought 
out first. I know there are alot of issues that need to be addressed 
with Recording and parameter file processing the would still need to be 
dealt with to properly allow array[] parameters into the model design. 
I'm not sure how enthusiastic your guys are about taking on such a 
project. I'm even encountering issues with arrays[] without using these 
parts of RePast (external in my Jelly Environment, which doesn't really 
have any clear functionality of instantiating/initializing arrays).

-Mark