ListView, registering view resources

When I execute the following code in 4.01, I get a notifier because a
commctrl message failed:

    ListPresenter addView: ListView asResource: 'test'

As a result, the view resource is sort of added to the ResourceManager, but
it doesn't really work.

Actually, I'm creating a subclass of ListView that allows editing any list
cell in report mode, not just the first one. However, the error doesn't seem
to be in my code as it also happens with ListView itself.

Hasko

Hasko,

> When I execute the following code in 4.01, I get a notifier because a
> commctrl message failed:
>
>     ListPresenter addView: ListView asResource: 'test'
>
> As a result, the view resource is sort of added to the ResourceManager,
but
> it doesn't really work.
>
> Actually, I'm creating a subclass of ListView that allows editing any list
> cell in report mode, not just the first one. However, the error doesn't
seem
> to be in my code as it also happens with ListView itself.

ListPresenter probably is the presenter class you want to use, but, try
specifying your new subclass rather than ListView.  No promises though :)

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab <[hidden email]> wrote in response to my question:
> > When I execute the following code in 4.01, I get a notifier because a
> > commctrl message failed:
> >
> >     ListPresenter addView: ListView asResource: 'test'
[...]
> > Actually, I'm creating a subclass of ListView that allows editing any
list
> > cell in report mode, not just the first one. However, the error doesn't
> seem
> > to be in my code as it also happens with ListView itself.
>
> ListPresenter probably is the presenter class you want to use, but, try
> specifying your new subclass rather than ListView.  No promises though :)

I'm not sure I understand. Do you mean I should write

    ListPresenter addView: MyListView asResource: 'test'

I did that, and got the error I described. I just noticed that the same
error happens with the original ListView class, so the error is not in my
code. However, I already wrote this in my previous post, so maybe I
misunderstood your point.

By the way, there is no new subclass of ListPresenter - all the logic is
handled in the new ListView subclass. It's all passing Windows messages to
and fro...

Hasko

Hasko,

> I did that, and got the error I described. I just noticed that the same
> error happens with the original ListView class, so the error is not in my
> code. However, I already wrote this in my previous post, so maybe I
> misunderstood your point.

This has been reported in the newsgroup before (Christopher Demers on 24
July 2000 at 23:40) but appears to have slipped through the OA bug fix list.

A temporary fix is just to comment out the code in ListView>>state (between
the last comment and the return statement) while you create the resource. I
think it's just caused by the API method needing the ListView to be created
"properly", as part of an open view, rather than just for the
ResourceManager.  Commenting out this short section will not affect anything
as it is only used to remember when the ListViewColumns are rearranged by
dragging the headers - something that won't have happened while the
ViewResource is being created.

Hopefully OA will address it is the next patch?

Ian

Folks,

> > I did that, and got the error I described. I just noticed that the same
> > error happens with the original ListView class, so the error is not in
my
> > code. However, I already wrote this in my previous post, so maybe I
> > misunderstood your point.
>
> This has been reported in the newsgroup before (Christopher Demers on 24
> July 2000 at 23:40) but appears to have slipped through the OA bug fix
list.
>
> A temporary fix is just to comment out the code in ListView>>state
(between
> the last comment and the return statement) while you create the resource.
I
> think it's just caused by the API method needing the ListView to be
created
> "properly", as part of an open view, rather than just for the
> ResourceManager.  Commenting out this short section will not affect
anything
> as it is only used to remember when the ListViewColumns are rearranged by
> dragging the headers - something that won't have happened while the
> ViewResource is being created.
>
> Hopefully OA will address it is the next patch?

I think the correct fix is to the View>>makeResource:inClass: method as
follows. The problem appears to be caused by the fact that a ListView
control does not behave correctly when it is made a child of the desktop.
The solution chosen is to create a temporary shell view to act as the parent
for all view being instantiated to add to the resource manager. This is now
recorded as defect #186 and the fix should appear in 4.01.2. In the meantime
can you verify that the following does address the problem for you:

View>>makeResource: aStringName inClass: aClass
    "Private - Save and instance of the receiver as a default writable
ViewResource
    called aString owned by aClass."

    | resID view shell |
    shell := ShellView new create.
    view := shell addSubView: self new.
    (resID := ResourceIdentifier class: aClass name: aStringName)
        assign: (ViewResource defaultWritable);
        save: view.
    shell destroy.
    ^resID

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com

---
Visit the Dolphin Smalltalk WikiWeb
http://www.object-arts.com/wiki/html/Dolphin/FrontPage.htm
---

Hasko Heinecke <[hidden email]> wrote in message
news:3ae2be55$[hidden email]...
>
> Actually, I'm creating a subclass of ListView that allows editing any list
> cell in report mode, not just the first one. However, the error doesn't
seem
> to be in my code as it also happens with ListView itself.
>

I was trying to do something similar some time ago.  I decided not to
subclass the view after all, but rather to subclass ListPresenter.  I would
then dynamically create or move a textbox to the new text entry position.  I
did some experiments with this approach and decided I was not really happy
with it.

I decided that I wanted more control over the whole thing, so I created an
emulated ListEditView.  I create a column of StaticText views and a column
of TextEdit views inside a ScrollDecorator.  This seems to work fairly well
for what I need.

If you want to see my code I have my new ListEditView here:
http://www.mitchellscientific.com/smalltalk/ and I even out up my old
ListPresenter subclass based code here:
http://www.mitchellscientific.com/smalltalk/ListEditPresenterOLD.cls .
Please note that the old code may look pretty bad, it was very experimental
stuff, and I never refined it.

Hopefully some of this code is of use to you.  I would also be interested in
knowing how you end up approaching a listEdit control.

Chris

Andy Bower <[hidden email]> wrote:
> I think the correct fix is to the View>>makeResource:inClass: method as
> follows.
[...]
> This is now
> recorded as defect #186 and the fix should appear in 4.01.2. In the
meantime
> can you verify that the following does address the problem for you:

Yes, with that fix adding a ListView resources works perfectly. Thanks a
lot!

BTW, there's a related bug in ListView that I reported to you erlier this
week: In ListView>>publishedAspectsOfInstances the class ListViewColumn is
directly referenced by name in an aspect string. This should really use the
class returned by #columnClass to allow subclassing of ListViewColumn. As a
result, #columnClass must become a class method. Will that be fixed in
4.01.2 as well?

Thanks again and have a nice day. (It's 6 a.m. here now...)

Hasko

Hasko,

> BTW, there's a related bug in ListView that I reported to you erlier this
> week: In ListView>>publishedAspectsOfInstances the class ListViewColumn is
> directly referenced by name in an aspect string. This should really use
the
> class returned by #columnClass to allow subclassing of ListViewColumn. As
a
> result, #columnClass must become a class method. Will that be fixed in
> 4.01.2 as well?

This has now been entered as an enhancement #190 and will be fixed for
4.01.2.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com

---
Visit the Dolphin Smalltalk WikiWeb
http://www.object-arts.com/wiki/html/Dolphin/FrontPage.htm
---

Hask,

> > BTW, there's a related bug in ListView that I reported to you erlier
this
> > week: In ListView>>publishedAspectsOfInstances the class ListViewColumn
is
> > directly referenced by name in an aspect string. This should really use
> the
> > class returned by #columnClass to allow subclassing of ListViewColumn.
As
> a
> > result, #columnClass must become a class method. Will that be fixed in
> > 4.01.2 as well?
>
> This has now been entered as an enhancement #190 and will be fixed for
> 4.01.2.

The fix I've chosen for this is to add the published aspect for the column
selection to an instance side #publishedAspects method (rather than by
creating a class side #columnClass method). The reason for this is to ensure
that if the instance side #columnClass method was ever overidden by a
subclass then the publish aspects would still be correct. The attached ST
file demonstrates the patch; let me know if this addresses your problem.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com

---
Visit the Dolphin Smalltalk WikiWeb
http://www.object-arts.com/wiki/html/Dolphin/FrontPage.htm
---
























begin 666 ListView column class patch.st
M#0HA3&ES=%9I97<@;65T:&]D<T9O<B$-"@T*<'5B;&ES:&5D07-P96-T<PT*
M"2)!;G-W97(@82 \4V5T/B!O9B!T:&4@87-P96-T<R!P=6)L:7-H960@8GD@
M=&AI<R!C;&%S<RXB#0H-"@E><W5P97(@<'5B;&ES:&5D07-P96-T<PT*"0EA
M9&0Z("A!<W!E8W0@;&ES=#H@(V-O;'5M;G-,:7-T(&%D9$5V86QU871I;VY&
M<F]M.B H07)R87D@=VET:#H@*'-E;&8@8V]L=6UN0VQA<W,@;F%M92P@)R!N
M97<G*2D@*3L-"@D)>6]U<G-E;&8A("$-"B%,:7-T5FEE=R!C871E9V]R:65S
M1F]R.B C<'5B;&ES:&5D07-P96-T<R$J+75N8VQA<W-I9FEE9"%P=6)L:6,A
M("$-"@T*(4QI<W16:65W(&-L87-S(&UE=&AO9'-&;W(A#0H-"G!U8FQI<VAE
M9$%S<&5C='-/9DEN<W1A;F-E<PT*"2)!;G-W97(@82!3970@;V8@=&AE(&%S
M<&5C=',@<'5B;&ES:&5D(&)Y("!I;G-T86YC97,@;V8@=&AE(')E8V5I=F5R
M(@T*#0H)7G-U<&5R('!U8FQI<VAE9$%S<&5C='-/9DEN<W1A;F-E<R -"@D)
M861D.B H07-P96-T(&-H;VEC93H@(W9I97=-;V1E(&9R;VTZ(",H<VUA;&Q)
M8V]N<R!L87)G94EC;VYS(&QI<W0@<F5P;W)T*2D[#0H)"6%D9#H@*$%S<&5C
M="!A=71O<W1R:6YG.B C=&5X="D[#0H)"6%D9#H@*$%S<&5C="!B;V]L96%N
M.B C:7-6:7)T=6%L*3L-"@D)861D.B H07-P96-T(&)O;VQE86XZ("-H87-#
M;VQU;6Y(96%D97)S*3L-"@D)861D.B H07-P96-T(&)O;VQE86XZ("-H87-&
M=6QL4F]W4V5L96-T*3L-"@D)861D.B H07-P96-T(&)O;VQE86XZ("-H87-'
M<FED3&EN97,I.PT*"0EA9&0Z("A!<W!E8W0@8F]O;&5A;CH@(VAA<TAE861E
M<D1R86=$<F]P*3L-"@D)861D.B H07-P96-T(&)O;VQE86XZ("-H87-#;VQU
M;6Y);6%G97,I.PT*"0EA9&0Z("A!<W!E8W0@8F]O;&5A;CH@(VAA<U1R86-K
M4V5L96-T*3L-"@D)861D.B H07-P96-T(&)O;VQE86XZ("-H87-3;W)T2&5A
M9&5R<RD[#0H)"6%D9#H@*$%S<&5C="!B;V]L96%N.B C:&%S1FQA=%-C<F]L
M;&)A<G,I.PT*"0EA9&0Z("A!<W!E8W0@8F]O;&5A;CH@(VAA<TEN9F]4:7!S
M*3L-"@D)861D.B H07-P96-T(&)O;VQE86XZ("-C86Y%9&ET3&%B96QS*3L-
M"@D)861D.B H07-P96-T(&)O;VQE86XZ("-S:&]W<U-E;$%L=V%Y<RD[#0H)
M"6%D9#H@*$%S<&5C="!B;V]L96%N.B C:&%S0VAE8VM";WAE<RD[#0H)"6%D
M9#H@*$%S<&5C="!N86UE.B C:6-O;E-P86-I;F<@8VAO;W-E1G)O;3H@(R@G
M,S) ,S(G*2D[#0H)"7)E;6]V94ME>3H@(W1E>'0[#0H)"7EO=7)S96QF(2 A
M#0HA3&ES=%9I97<@8VQA<W,@8V%T96=O<FEE<T9O<CH@(W!U8FQI<VAE9$%S
M<&5C='-/9DEN<W1A;F-E<R%C;VYS=&%N=',A9&5V96QO<&UE;G0A<'5B;&EC
'(2 A#0H-"@``
`
end