stretchFactor=1.0 worked
=o)
detail.makeArea( parcel, "RawVCardArea", baseClass=RawVCardAreaBlock, # this makes the area conditionally visible childrenBlocks=[ detail.makeEditor( parcel, 'RawVCard', viewAttribute=u'rawVCard', presentationStyle={ 'lineStyleEnum': 'MultiLine', 'format': 'contactRawVCardField' }, ) ], stretchFactor = 1.0, # prevents multiline text area from being squeezed position=0.951 ).install(parcel),
Le 10 août 06 à 17:43, Bryan Stearns a écrit : Ernesto, Ah, I think I see what's happening. Thanks for the explanation about your attribute editor - that part sounds like everything's right. I think the problem has to do with the extra block layer between the root of the detail view and your raw text area's block: you've got: DetailRoot # the root of the detail view RawVCardArea # DetailSynchronizedContentItemDetail subclass that controls visibility RawVCard # DetailSynchronizedAttributeEditorBlock that ends up hosting your custom AE. It might work better if it's: DetailRoot # the root of the detail view RawVCardAEBlock # DetailSynchronizedAttributeEditorBlock that controls visibility _and_ hosts your custom AE As an example, in Detail.py, the Appears In field's block is subclassed this way to control its visibility without an extra layer. (I don't know why it's not working the way you have it - there ought to be a way to lay it out with the extra level, but I don't have time right now to dig into that - sizing can be a time sink! - and since I don't think you're getting extra benefit from the extra layer anyway, I'm suggesting you remove it.) The height=200 in your makeEditor call might work if you do this, or might not; if it doesn't, try it without it or with stretchFactor=1.0 instead (which should mean that your text area and the Notes body split any left-over space). ...Bryan Ernesto Rivera wrote: The makeEditor function makes an AEBlock, a block that hosts an attribute editor. Attribute editors are picked at runtime based on the type of the value in the configured attribute; in your case, you're telling it to edit the 'rawVCard' attribute. I don't know what the declared type of the 'rawVCard' attribute is, but I'm guessing it's schema.Text, like ContentItem's 'body'. Yes, it's a schema.Text The picking mechanism also uses the presentationStyle.format attribute, if present, to influence the picking process. You're saying that the format is 'contactRawVCardField', so it's going to look first for an attribute editor registered to handle 'Text+contactRawVCardField'. I'm assuming that you didn't write a custom attribute editor, so it's not going to find one - it will fall back and look for one for just 'Text', and will find StringAttributeEditor (which is what gets used for the Note body as well). I actually wrote. I needed my own attribute editor to ensure sync of the raw vCard field with the other "user friendly" contact fields. For this I wrote: class ContactRawVCardAE(StringAttributeEditor): def GetAttributeValue(self, item, attributeName): ... def SetAttributeValue(self, item, attributeName, valueString): ... and I registered the custom editor with: def registerAttributeEditors(parcel, oldVersion=None): aeDict = { 'Text+contactRawVCardField': 'ContactRawVCardAE' } AttributeEditorMapping.register(parcel, aeDict, __name__) And this works nicely. The custom AE is a subclass of the string editor, so I think for many calls the string editor's methods will be used. Note: I had this "squeeze" problem even before creating a custom editor. StringAttributeEditor should do the right thing and build a multiline text area since you've given it that lineStyleEnum 'MultiLine' value. I'm not sure why it's not, or what you mean by "it works if the block is moved outside childrenBlocks" - where are you moving it to that it's still appearing? Yes, if I have the makeEditor block a root component of the blocks three it displays correctly. If I move it inside a makeArea Sublock it then gets squeezed. block three -> makeEditor: works displaying multilines block three-> makeArea-> makeEditor: the editor gets squeezed to a single line with a very little scroll bar. The note's item content is not enclosed in a block area, thus displays correctly... (If you did write a custom attribute editor that you've registered to handle Text+contactRawVCardField, it'd need the same logic in its createControl method as StringAttributeEditor has - you can see that it's a matter of passing a different style value to the control being created. I'm not saying you _should_ create a custom attribute editor, especially right before your demo -- I'm just trying to explain what happens if you have.) I wouldn't be surprised if specifying the height didn't work at all, no matter where you say "height=...". Our only use case for the multiline editor is for the note body, to have it take up "the rest of the space" (that is, they stretch to take up the rest of the detail view after all the smaller fields are laid out. I think the certificate detail view shows more than one multiline text field, and they all share that space - you might ask Heikki about that. ...Bryan Thanks, Ernesto Ernesto Rivera wrote: Hi, I am doing some last changes to contacts' code before tomorrow's presentations. I have this annoying issue with this 'RawVCard' that is displayed "squeezed" as text field instead of a text area (multiline text): contactPersonRootBlocks = [... detail.makeArea( parcel, "RawVCardArea", baseClass=RawVCardAreaBlock, # this makes the area conditionally visible height = 200, # <-- didn't expanded the detail area either childrenBlocks=[ detail.makeEditor( # displays as a text field instead of as a text area parcel, 'RawVCard', viewAttribute=u'rawVCard', presentationStyle={ 'lineStyleEnum': 'MultiLine', #<-- this works the block is moved outside childrenBlocks 'format': 'contactRawVCardField' }, height = 200 # doesn't seem to work ) ], position=0.951 ).install(parcel), The problem occurs on both alpha2 and 3. Also the the field displays correctly when outside the detail.makeArea, so the issue is only for text areas declared as childrenBlocks. Any ideas? Thanks, Ernesto _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
|