hi,

i did have made some "native" Control with ot4xb for Xbase++.

they work fine but when i try to "mix" Xbase++ Ownerdraw and
"native" Ownerdraw it will "override" Xbase XBP_DRAW_OWNERADVANCED

i include 3 Demo in Sample for ListBox

1.) Sample "pure" Xbase++

 oda_lbox.EXE      -> "pure" Xbase++
 oda_lbox.EXE 1   -> "pure" Xbase++ XBP_DRAW_OWNER
 oda_lbox.EXE 2   -> "pure" Xbase++ XBP_DRAW_OWNERADVANCED

2.) Sample with 2x ListBox ("pure", "native")

 dxe_LBOX.EXE     -> both "normal"
 dxe_LBOX.EXE 1  -> XBP_DRAW_OWNER , right "internal"
 dxe_LBOX.EXE 2  -> XBP_DRAW_OWNERADVANCED , right "internal"
 dxe_LBOX.EXE 3  -> XBP_DRAW_OWNER , right "Codeblock"
 dxe_LBOX.EXE 4  -> XBP_DRAW_OWNERADVANCED , right "Codeblock"

3.) Sample with @User32:DlgDirListA() like Directory()

  dxe_LDIR.EXE     -> both XBP_DRAW_OWNERADVANCED

it seem me to happend to all Ownerdraw XbParts when using Measureitem 
Structure ?
is it while ::oMeasureitemstruct:CtlID allways give 0 for XbParts ?


Question : did someone have "Cockpit" or "Yukon" to verify it ?

greetings by OGR
Jimmy 

Hello Jimmy,
unfortunately you didn't provide any source code. However, I would like to 
point out that inrerecpting the WM_PAINT message, doing some painting and 
passing on to other window procedures for further painting isn't easy. 
That's because you have to call BeginPaint/EndPaint and the O/S takes care 
of update regions.
Best regards,
Michael

"AUGE_OHR" <AUGE_OHR*AT*WEB.DE> wrote in message 
news:1e274ba0$50e893d1$1e422@news.alaska-software.com...
> hi,
>
> i did have made some "native" Control with ot4xb for Xbase++.
>
> they work fine but when i try to "mix" Xbase++ Ownerdraw and
> "native" Ownerdraw it will "override" Xbase XBP_DRAW_OWNERADVANCED
>
> i include 3 Demo in Sample for ListBox
>
> 1.) Sample "pure" Xbase++
>
> oda_lbox.EXE      -> "pure" Xbase++
> oda_lbox.EXE 1   -> "pure" Xbase++ XBP_DRAW_OWNER
> oda_lbox.EXE 2   -> "pure" Xbase++ XBP_DRAW_OWNERADVANCED
>
> 2.) Sample with 2x ListBox ("pure", "native")
>
> dxe_LBOX.EXE     -> both "normal"
> dxe_LBOX.EXE 1  -> XBP_DRAW_OWNER , right "internal"
> dxe_LBOX.EXE 2  -> XBP_DRAW_OWNERADVANCED , right "internal"
> dxe_LBOX.EXE 3  -> XBP_DRAW_OWNER , right "Codeblock"
> dxe_LBOX.EXE 4  -> XBP_DRAW_OWNERADVANCED , right "Codeblock"
>
> 3.) Sample with @User32:DlgDirListA() like Directory()
>
>  dxe_LDIR.EXE     -> both XBP_DRAW_OWNERADVANCED
>
> it seem me to happend to all Ownerdraw XbParts when using Measureitem 
> Structure ?
> is it while ::oMeasureitemstruct:CtlID allways give 0 for XbParts ?
>
>
> Question : did someone have "Cockpit" or "Yukon" to verify it ?
>
> greetings by OGR
> Jimmy
>
>

hi,

thx for Answer.

i do not think its a WM_PAINT Problem, it is a "measure" Problem.

as i say both "native" and "pure" Xbase++ Version work as Standalone
with XBP_DRAW_OWNERADVANCED or XBP_DRAW_OWNER.

when "mix" Xbase++ "pure" with "native" Control, Xbase++ will "switch back"
to XBP_DRAW_OWNER in "pure" Version so MeasureItem is fired "once" only ?

while both must use MeasureItem Structure ...

Question : can OS() use it 2x MeasureItem Structure ?







when using XBP_DRAW_OWNERADVANCED i want to change
Items heigh ( %2 <> 0 ) so i have to "write back" into Structure ...


 INLINE METHOD ApplyOwnerDraw(lOnOff)
    ::oDrawItemStruct       := DRAWITEMSTRUCT():NEW()
    ::oMeasureitemstruct    := MEASUREITEMSTRUCT():NEW()
...
 INLINE METHOD My_MEASUREITEM(wp,lp)
...
    use _write()_ to made it "read" Member
   ::oMeasureitemstruct:_write_(lp,0,-1)

    only use "my" Control CtlID
    IF ::oMeasureitemstruct:CtlType = ODT_LISTBOX .AND. ;
        ::oMeasureitemstruct:CtlID   = APP_ID_LISTBOX
       IF ( ::oMeasureitemstruct:itemID % 2) <> 0
         ::oMeasureitemstruct:itemHeight :=::oMeasureitemstruct:itemHeight*2

          need after change ? YES when used _write_() !!!
         ::oMeasureitemstruct:_read_(lp,0,-1)
       ENDIF
    ENDIF

Question : do i have to "lock" Structure for read/write ? i yes how ?






as i figure out XbParts seems allways to use 0 (zero) for CrtlID

   hWnd    := oXbp:GetHWnd()
   nCtrlID := @user32:GetWindowLongA(HWnd , GWL_ID )

this might work with Xbase++ "pure" when not "test" for CtlID
but what about my "native" Control ... it "send" to "same" (???)
Windows Queue.





while i use ot4xb i ask for "Cockpit" / "Yukon" User if that happend too.

greetings by OHR
Jimmy

Hello Jimmy,

straight from MSDN:

"The owner window of an owner-drawn control receives a pointer to the 
MEASUREITEMSTRUCT structure as the lParam parameter of a WM_MEASUREITEM 
message. The owner-drawn control sends this message to its owner window when 
the control is created."

I would read from this that the size is determined only once, after that it 
cannot be changed.

Best regards,
Michael


"AUGE_OHR" <AUGE_OHR*AT*WEB.DE> wrote in message 
news:743c0034$1827b8c0$3e909@news.alaska-software.com...
> hi,
>
> thx for Answer.
>
> i do not think its a WM_PAINT Problem, it is a "measure" Problem.
>
> as i say both "native" and "pure" Xbase++ Version work as Standalone
> with XBP_DRAW_OWNERADVANCED or XBP_DRAW_OWNER.
>
> when "mix" Xbase++ "pure" with "native" Control, Xbase++ will "switch 
> back"
> to XBP_DRAW_OWNER in "pure" Version so MeasureItem is fired "once" only ?
>
> while both must use MeasureItem Structure ...
>
> Question : can OS() use it 2x MeasureItem Structure ?
>
>
>
>
>
>
>
> when using XBP_DRAW_OWNERADVANCED i want to change
> Items heigh ( %2 <> 0 ) so i have to "write back" into Structure ...
>
>
> INLINE METHOD ApplyOwnerDraw(lOnOff)
>    ::oDrawItemStruct       := DRAWITEMSTRUCT():NEW()
>    ::oMeasureitemstruct    := MEASUREITEMSTRUCT():NEW()
> ...
> INLINE METHOD My_MEASUREITEM(wp,lp)
> ...
>    use _write()_ to made it "read" Member
>   ::oMeasureitemstruct:_write_(lp,0,-1)
>
>    only use "my" Control CtlID
>    IF ::oMeasureitemstruct:CtlType = ODT_LISTBOX .AND. ;
>        ::oMeasureitemstruct:CtlID   = APP_ID_LISTBOX
>       IF ( ::oMeasureitemstruct:itemID % 2) <> 0
>         ::oMeasureitemstruct:itemHeight 
> :=::oMeasureitemstruct:itemHeight*2
>
>          need after change ? YES when used _write_() !!!
>         ::oMeasureitemstruct:_read_(lp,0,-1)
>       ENDIF
>    ENDIF
>
> Question : do i have to "lock" Structure for read/write ? i yes how ?
>
>
>
>
>
>
> as i figure out XbParts seems allways to use 0 (zero) for CrtlID
>
>   hWnd    := oXbp:GetHWnd()
>   nCtrlID := @user32:GetWindowLongA(HWnd , GWL_ID )
>
> this might work with Xbase++ "pure" when not "test" for CtlID
> but what about my "native" Control ... it "send" to "same" (???)
> Windows Queue.
>
>
>
>
>
> while i use ot4xb i ask for "Cockpit" / "Yukon" User if that happend too.
>
> greetings by OHR
> Jimmy
>
>
>
>
>
>
>
>
>
>
>
>
>

hi,

> "The owner window of an owner-drawn control receives a pointer to the 
> MEASUREITEMSTRUCT structure as the lParam parameter of a WM_MEASUREITEM 
> message. The owner-drawn control sends this message to its owner window 
> when the control is created."


If a list box or combo box is created with the LBS_OWNERDRAWVARIABLE
or CBS_OWNERDRAWVARIABLE style, this message is sent to the owner
for each item in the control; otherwise, this message is sent once.

as  i say each Sample works as Standalone with XBP_DRAW_OWNER
and with XBP_DRAW_OWNERADVANCED , but "pure" Xbase++
Sample will fall back to XBP_DRAW_OWNER when "mix" with "native"

Question : if System send WM_MEASUREITEM how does a Control
( "pure" or "native" ) know that "this" Event is to be handle by "that"
Control and not by a "other" Control ?

if it is ::oMeasureitemstruct:CtlID / :oDrawItemStruct:CtlID how can
Xbase++ "react" on it if "CtlID" is 0 ?


greetings by OHR
Jimmy

Hello Jimmy,

>
> If a list box or combo box is created with the LBS_OWNERDRAWVARIABLE
> or CBS_OWNERDRAWVARIABLE style, this message is sent to the owner
> for each item in the control; otherwise, this message is sent once.

Correct.

>
> as  i say each Sample works as Standalone with XBP_DRAW_OWNER
> and with XBP_DRAW_OWNERADVANCED , but "pure" Xbase++
> Sample will fall back to XBP_DRAW_OWNER when "mix" with "native"

I don't know what "mix" with "native" means and I'm not sure if I want to 
know.

>
> Question : if System send WM_MEASUREITEM how does a Control
> ( "pure" or "native" ) know that "this" Event is to be handle by "that"
> Control and not by a "other" Control ?

It doesn't because the parent receives the event. Normally the parent will 
identify
the control via its item ID.

>
> if it is ::oMeasureitemstruct:CtlID / :oDrawItemStruct:CtlID how can
> Xbase++ "react" on it if "CtlID" is 0 ?

Maybe it's taking down the window handle when the control is sent a message
which results in this query to the owner. Maybe they are using message 
filters.
Or maybe they are indeeded assigning ctrl ids. Have you checked?

Best regards
Michael

hi,

> I don't know what "mix" with "native" means and I'm not sure if I want to
> know.

see Sample where i use 2x ListBox in same Dialog.
one is "pure" Xbase++ other is "native"

> Maybe it's taking down the window handle when the control is sent a
> message which results in this query to the owner.
> Maybe they are using message filters.
> Or maybe they are indeeded assigning ctrl ids. Have you checked?

Yes  :

PROCEDURE TestHwnd(hWnd,cText,cAction)
LOCAL nCtrlID := 0
LOCAL nStyle  := 0

       get CtlID
      nCtrlID := @user32:GetWindowLongA(HWnd , GWL_ID )

       get Style
      nStyle  := @user32:GetWindowLongA(hWnd, GWL_STYLE)
      TestStyle(nStyle,cAction)

RETURN

greetings by OHR
Jimmy

Hello Jimmy,
I fail to see where this thing is going. Where does the measureitemstruct 
come into play? Xbase provides a callback in which you can specify the 
sizes. If  Pablo does some hooking and provides you with the O/S structure, 
why don't you simply assing a control id to the xbase / native listview?
Best regards,
Michael

"AUGE_OHR" <AUGE_OHR*AT*WEB.DE> wrote in message 
news:2a8ab049$4dd6949c$9058@news.alaska-software.com...
> hi,
>
>> I don't know what "mix" with "native" means and I'm not sure if I want to
>> know.
>
> see Sample where i use 2x ListBox in same Dialog.
> one is "pure" Xbase++ other is "native"
>
>> Maybe it's taking down the window handle when the control is sent a
>> message which results in this query to the owner.
>> Maybe they are using message filters.
>> Or maybe they are indeeded assigning ctrl ids. Have you checked?
>
> Yes  :
>
> PROCEDURE TestHwnd(hWnd,cText,cAction)
> LOCAL nCtrlID := 0
> LOCAL nStyle  := 0
>
>       get CtlID
>      nCtrlID := @user32:GetWindowLongA(HWnd , GWL_ID )
>
>       get Style
>      nStyle  := @user32:GetWindowLongA(hWnd, GWL_STYLE)
>      TestStyle(nStyle,cAction)
>
> RETURN
>
> greetings by OHR
> Jimmy
>
>
>

hi,


>Where does the measureitemstruct come into play?

i "think" all Common Controls, which can use Ownerdraw, must use Measureitem 
Structure.


>Xbase provides a callback in which you can specify the sizes.

yes shure Xbase++ is doing something "inside",  but it must use Measureitem 
Structure too, or ?

i agree that im doing somethong "outside" Xbase++ but it is still Win OS() 
so what is Xbase++ doing "inside" ?

while Alaska do not provide these Information we can just guess what might 
happend ...
this is why i open this Thread and ask for it.

greetings by OHR
Jimmy

Hello Jimmy,

"AUGE_OHR" <AUGE_OHR*AT*WEB.DE> wrote in message 
news:6065d9ce$46deb401$39c9@news.alaska-software.com...
> hi,
>
>
>>Where does the measureitemstruct come into play?
>
> i "think" all Common Controls, which can use Ownerdraw, must use 
> Measureitem Structure.

But where do you get a hold of it?

>
>
>>Xbase provides a callback in which you can specify the sizes.
>
> yes shure Xbase++ is doing something "inside",  but it must use 
> Measureitem Structure too, or ?
>
> i agree that im doing somethong "outside" Xbase++ but it is still Win 
> OS() so what is Xbase++ doing "inside" ?

It's running a separate message loop in the GUI thread and posts the O/S 
messages
over to the thread that created the xbase parts after translating and 
filtering
them.. This is a great thing because the GUI won't get "stuck" when you're
mingling data in your thread. And this is a bad thing because it's 
flickering
like hell while interchanging messages between threads.

>
> while Alaska do not provide these Information we can just guess what might 
> happend ...
> this is why i open this Thread and ask for it.

Very well, but I still didn't understand your problem. What did you exactly 
do in
your program and what effect exactly do you see? Did you add a native 
control?
In which thread did you add it? How do your intercept it's messages? Do you
expect Xbase to forward it's messages/notifications to your thread?

Best regards,
Michael

hi,

thx for Answer

> Very well, but I still didn't understand your problem.

Xbparts  XBP_DRAW_OWNERADVANCED will "fall back"
to  XBP_DRAW_OWNER when "mix" with my "native" Controls

> What did you exactly do in your program and what effect exactly do you 
> see?

using Measureitem Structure in my "native" Control have Sideeffect with same 
XbPart


> Did you add a native  control?

yes ( see Sample )

> In which thread did you add it?

i "think" when Sub_Class with ot4xb "native" Control will run in GUI Thread 
?

> How do your intercept it's messages?

   ot4xb_subclasswindow(::hXbp,Self,,"xbp_wndproc")
   @User32:SendMessageA( ::hXbp,WM_USER+1,0,0)

INLINE METHOD Xbp_wndproc(hWnd,nMsg,wp,lp,ctx)
...
   IF nMsg == (WM_USER + 1 )
      ::m_ht := _hdict_new()
      rc := {0,0,0,0}
      @User32:GetClientRect(hWnd,@rc)
      @User32:SetWindowLongA(hWnd,GWL_EXSTYLE,;
          nOr(@User32:GetWindowLongA(hWnd,GWL_EXSTYLE),WS_EX_CONTROLPARENT))

      ::hLBox := @User32:CreateWindowExA(0 ,;      extended styles
                           ::cClassName    ,;      control 'class' name 
"ListBox"
                           ""                          ,;      control 
caption
                           ::dwLvStyle         ,;      wnd Style
                           0,0,rc[3],rc[4]      ,;      position: 
left,top,width,height
                           ::hXbp                 ,;      parent window 
handle
                           APP_ID_LISTBOX  ,;      control's ID
                           AppInstance()    ,;      instance Ot4Xb -> 
GetModuleHandleA()
                           0)                                 user defined 
info

      @user32:SendMessageA( ::hLBox, WM_SETFONT , ::hFont , 0)


 for Ownerdraw

   ELSEIF nMsg == WM_MEASUREITEM
      ::My_MEASUREITEM(wp,lp)
      RETURN 1

   ELSEIF nMsg == WM_DRAWITEM
      ::My_DRAWITEM(wp,lp)
      RETURN 1
...


INLINE METHOD My_MEASUREITEM(wp,lp)
...
 use write to made it "read" Member
   ::oMeasureitemstruct:_write_(lp,0,-1)

 this i can use to identify my "native" Control when used Ownerdraw
   IF ::oMeasureitemstruct:CtlType = ODT_LISTBOX .AND. ;
       ::oMeasureitemstruct:CtlID   = APP_ID_LISTBOX

so my "native" Control work as it should (?) in both case "standalone"
and when "mix" with same XbPart. it is the XbPart which will "fall back"

this is what my Sample show and i ask why Xbase++ fail. in this case ?


> Do you expect Xbase to forward it's messages/notifications to your thread?

no while "my" Thread seem to work perfect, but i can forward Msg from my 
Thread into Xbase++



Question :

if i got WM_MEASUREITEM but ::oMeasureitemstruct:CtlID <> APP_ID_LISTBOX 
what happend to WM_MEASUREITEM ?

greetings by OHR
Jimmy

Hello Jimmy,
unfortunately I don't know abou the innner workings of Pablo's functions and 
the more code you show me the more blurred my picture of your programm gets 
for me. However, I'll try a shot in the dark. The WM_MEASUREITEM message is 
sent to the parent of the control which would be the XbpDialog's 
MDIClientWindow. This little friend has to cope with all notifications, 
messages, commands, whatever it receives from it's beastly children. And 
everything depends entirely on what it does with these messages. Maybe it 
echoes them back to the controls, which would mean there would be a message 
identifier translation we don't know about. Maybe it handles some of them 
and maybe it sends some over to the "normal" Xbase message handling thread. 
Now, if you put in a native control (I can only hope this happens in the 
internal GUI thread...) on the XbpDialog (actually its MdiChildWindow), then 
our little friend might get a bit confused by some messages it's presented 
with, particularly their origin and in turn routes them incorrectly.
HTH,
Michael


"AUGE_OHR" <AUGE_OHR*AT*WEB.DE> wrote in message 
news:1c87998d$6b532e53$88b3@news.alaska-software.com...
> hi,
>
> thx for Answer
>
>> Very well, but I still didn't understand your problem.
>
> Xbparts  XBP_DRAW_OWNERADVANCED will "fall back"
> to  XBP_DRAW_OWNER when "mix" with my "native" Controls
>
>> What did you exactly do in your program and what effect exactly do you 
>> see?
>
> using Measureitem Structure in my "native" Control have Sideeffect with 
> same XbPart
>
>
>> Did you add a native  control?
>
> yes ( see Sample )
>
>> In which thread did you add it?
>
> i "think" when Sub_Class with ot4xb "native" Control will run in GUI 
> Thread ?
>
>> How do your intercept it's messages?
>
>   ot4xb_subclasswindow(::hXbp,Self,,"xbp_wndproc")
>   @User32:SendMessageA( ::hXbp,WM_USER+1,0,0)
>
> INLINE METHOD Xbp_wndproc(hWnd,nMsg,wp,lp,ctx)
> ...
>   IF nMsg == (WM_USER + 1 )
>      ::m_ht := _hdict_new()
>      rc := {0,0,0,0}
>      @User32:GetClientRect(hWnd,@rc)
>      @User32:SetWindowLongA(hWnd,GWL_EXSTYLE,;
> 
> nOr(@User32:GetWindowLongA(hWnd,GWL_EXSTYLE),WS_EX_CONTROLPARENT))
>
>      ::hLBox := @User32:CreateWindowExA(0 ,;      extended styles
>                           ::cClassName    ,;      control 'class' name 
> "ListBox"
>                           ""                          ,;      control 
> caption
>                           ::dwLvStyle         ,;      wnd Style
>                           0,0,rc[3],rc[4]      ,;      position: 
> left,top,width,height
>                           ::hXbp                 ,;      parent window 
> handle
>                           APP_ID_LISTBOX  ,;      control's ID
>                           AppInstance()    ,;      instance Ot4Xb -> 
> GetModuleHandleA()
>                           0)                                 user 
> defined info
>
>      @user32:SendMessageA( ::hLBox, WM_SETFONT , ::hFont , 0)
>
> 
>  for Ownerdraw
> 
>   ELSEIF nMsg == WM_MEASUREITEM
>      ::My_MEASUREITEM(wp,lp)
>      RETURN 1
>
>   ELSEIF nMsg == WM_DRAWITEM
>      ::My_DRAWITEM(wp,lp)
>      RETURN 1
> ...
>
>
> INLINE METHOD My_MEASUREITEM(wp,lp)
> ...
>  use write to made it "read" Member
>   ::oMeasureitemstruct:_write_(lp,0,-1)
>
>  this i can use to identify my "native" Control when used Ownerdraw
>   IF ::oMeasureitemstruct:CtlType = ODT_LISTBOX .AND. ;
>       ::oMeasureitemstruct:CtlID   = APP_ID_LISTBOX
>
> so my "native" Control work as it should (?) in both case "standalone"
> and when "mix" with same XbPart. it is the XbPart which will "fall back"
>
> this is what my Sample show and i ask why Xbase++ fail. in this case ?
>
>
>> Do you expect Xbase to forward it's messages/notifications to your 
>> thread?
>
> no while "my" Thread seem to work perfect, but i can forward Msg from my 
> Thread into Xbase++
>
>
>
> Question :
>
> if i got WM_MEASUREITEM but ::oMeasureitemstruct:CtlID <> APP_ID_LISTBOX 
> what happend to WM_MEASUREITEM ?
>
> greetings by OHR
> Jimmy
>
>
>
>
>
>
>
>

hi,

thx for Answer, but you still think my "native" Control make Problem ?

my "native" Controls does work as Stanalone or when "mix" with XbParts

my "native" Control do get every WM_MEASUREITEM message
it is the XbPart which get WM_MEASUREITEM message only 1x
when "mix" it with my "native" Control so Xbase++ will "fall back"
from XBP_DRAW_OWNERADVANCED  to XBP_DRAW_OWNER
not my "native" Control

if you have a Cockpit Sample of a "native" Control using Ownerdraw
we could verify if same happend with Cockpit like with ot4xb

greetings by OHR
Jimmy

Hello Jimmy,

> hi,
>
> thx for Answer, but you still think my "native" Control make Problem ?

You are not answering to the questions I'm asking while I'm trying to find 
out
where the problem lies. You must understand or at least have a theory of
what's going on behind the scenes before trying what you do. Otherwise
we're getting nowhere.

>
> my "native" Controls does work as Stanalone or when "mix" with XbParts
>
> my "native" Control do get every WM_MEASUREITEM message
> it is the XbPart which get WM_MEASUREITEM message only 1x
> when "mix" it with my "native" Control so Xbase++ will "fall back"
> from XBP_DRAW_OWNERADVANCED  to XBP_DRAW_OWNER
> not my "native" Control

What is this "falling back" theory? Why should it "fall back"? You're 
messing
with the natural flow of  messages and with what Xbase was designed to
live with. Maybe Windows gets confused too.

>
> if you have a Cockpit Sample of a "native" Control using Ownerdraw
> we could verify if same happend with Cockpit like with ot4xb

I don't see a point in doing that. What do you want to prove or see proven?

Best regards,
Michael

hi,

>> thx for Answer, but you still think my "native" Control make Problem ?
>
> You are not answering to the questions I'm asking while I'm trying to find
> out where the problem lies.

sorry to say again, not my "native" Control seems to make Problem.

while i send all my "native" Controls to Pablo to let him "see"
and "comment it" what i did, so i "think" i did not made a big
mistake in Source using Ot4xb.





> You must understand or at least have a theory of
> what's going on behind the scenes before trying what you do.
> Otherwise we're getting nowhere.

my Theorie is that Xbase++ Ownerdraw does not work well
when "mix" with "native" Controls or 3PP where Xbase++
have the "same" Control as XbPart.





> What is this "falling back" theory?

this is what Sample show
2.) Sample with 2x ListBox ("pure", "native")


> Why should it "fall back"?

this is my Question





> You're  messing with the natural flow of  messages and with what
> Xbase was designed to live with. Maybe Windows gets confused too.

may be Alaska does not expect that someone "else"
would make "same" Control as "native" using Ownerdraw ?

Alaska "seems" not to use Control ID like in Sample Progressbar

   nHWND := CreateWindowExA( 0,;
                             PROGRESS_CLASSA,;
                             0,;
                             ::nStyles, ;
                             0,0, aSize[1],aSize[2],      ;
                             ::SetParent():GetHWND(),;
                             0,  ;                Control ID -> CtlID
                             GetModuleHandleA(0),;
                             0 )

so perhaps Xbase++ can "identify" ::oMeasureitemstruct:CtlID = 0 ?





>> if you have a Cockpit Sample of a "native" Control using Ownerdraw
>> we could verify if same happend with Cockpit like with ot4xb
>
> I don't see a point in doing that.
> What do you want to prove or see proven?

i do ask for a Cockpit Sample while i did not found Ownerdraw in Demos.

i guess Cockpit can use Ownerdraw while found MEASUREITEM Structure,
but i did not found any Sample how Cockpit will use it.

i just want to compare if Cockpit get same Problem with Xbase++
when Cockpit use a "native" Control with Ownerdraw.

greetings by OHR
Jimmy

Hi Jimmy,

If you can mount a simple dialog with 2 customdraw listbox in pure Xbase++ and reproduce this missbehavior, probably will be usefull to show the issue here. If both have the same ID probably Xbase++ will have a trouble dispatching WM_MEASUREITEM correctly unless they using another mechanism to do it.

You can use the winspy tool from the www.catch22.net site to see the details of the controls, so you can see if all the controls share same ID.

Regards,

Pablo

hi,

> If you can mount a simple dialog with 2 customdraw listbox in pure Xbase++
>and reproduce this missbehavior, probably will be usefull to show the issue 
>here.

thx for your Idee and Sample.
i did build-in 3rd Listbox with my "native" Control

i look at your :measureItem := {|pos,aDim,o| aDim[2] := o:cargo }
and enhance it to

:measureItem := {|pos,aDim,o| IF( pos % 2 <> 0,;
                                      aDim[2] := o:cargo,;
                                      aDim[2] := o:cargo*2 ) }

and it still works (see Sample) ... hm

while my measureItem based on GraQueryTextBox( oPS, cCaption )
try Sample with "Test.EXE 2" ... and it still works ... hm

i also disable ( not create ) middle Listbox when use "Test.EXE 3"
 ... and it still works ... hm

so i have to figure out what make the differnce from my Sample
(not working) to your Sample (working ... as usual)

greetings by OHR
Jimmy

here the "pure" Xbase++ Ownerdraw Source i use for "mix" Sample

greetings by OHR
Jimmy

Hallo Jimmy,
this thread can go on theorizing for decades and we'll still be on square 
zero.
In my opinion you should get the facts straight (who creates which control
in which thread and who receives and forwards which messages where)
before composing fall-back theories. You have to accept the fact that
the Xbase++ GUI was not built to allow and support "intruders". This is
not a defect. If you're smuggling your native controls into the Xbase++
UI thread, then you have to take care of message routing. But then, again,
you must know what you're doing and how Windows expects messages
to be handled. I've tried to contact Pablo on this issue via private email
because we're playing in his backyard here, but unfortuntaly I seem to
have fallen prey to his spam filter.
Best regards,
Michael

"AUGE_OHR" <AUGE_OHR*AT*WEB.DE> wrote in message 
news:485e9e04$f441d58$173ca@news.alaska-software.com...
> hi,
>
>>> thx for Answer, but you still think my "native" Control make Problem ?
>>
>> You are not answering to the questions I'm asking while I'm trying to 
>> find
>> out where the problem lies.
>
> sorry to say again, not my "native" Control seems to make Problem.
>
> while i send all my "native" Controls to Pablo to let him "see"
> and "comment it" what i did, so i "think" i did not made a big
> mistake in Source using Ot4xb.
>
>
>
>
>
>> You must understand or at least have a theory of
>> what's going on behind the scenes before trying what you do.
>> Otherwise we're getting nowhere.
>
> my Theorie is that Xbase++ Ownerdraw does not work well
> when "mix" with "native" Controls or 3PP where Xbase++
> have the "same" Control as XbPart.
>
>
>
>
>
>> What is this "falling back" theory?
>
> this is what Sample show
> 2.) Sample with 2x ListBox ("pure", "native")
>
>
>> Why should it "fall back"?
>
> this is my Question
>
>
>
>
>
>> You're  messing with the natural flow of  messages and with what
>> Xbase was designed to live with. Maybe Windows gets confused too.
>
> may be Alaska does not expect that someone "else"
> would make "same" Control as "native" using Ownerdraw ?
>
> Alaska "seems" not to use Control ID like in Sample Progressbar
>
>   nHWND := CreateWindowExA( 0,;
>                             PROGRESS_CLASSA,;
>                             0,;
>                             ::nStyles, ;
>                             0,0, aSize[1],aSize[2],      ;
>                             ::SetParent():GetHWND(),;
>                             0,  ;                Control ID -> CtlID
>                             GetModuleHandleA(0),;
>                             0 )
>
> so perhaps Xbase++ can "identify" ::oMeasureitemstruct:CtlID = 0 ?
>
>
>
>
>
>>> if you have a Cockpit Sample of a "native" Control using Ownerdraw
>>> we could verify if same happend with Cockpit like with ot4xb
>>
>> I don't see a point in doing that.
>> What do you want to prove or see proven?
>
> i do ask for a Cockpit Sample while i did not found Ownerdraw in Demos.
>
> i guess Cockpit can use Ownerdraw while found MEASUREITEM Structure,
> but i did not found any Sample how Cockpit will use it.
>
> i just want to compare if Cockpit get same Problem with Xbase++
> when Cockpit use a "native" Control with Ownerdraw.
>
> greetings by OHR
> Jimmy
>

Hi Michael and Jimmy,

> this thread can go on theorizing for decades and we'll still be on square 
> zero.
100% agree. It's time to close it

Like I was sugested Jimmy since the first I was mount a simple test using just 2 ListBox XBPs
in pure Xbase++ with no ot4xb or any other extra stuff ( See Attached)

Results reveals 2 things

 both listboxes uses 0 as the control ID
 callbacks seems to be dispatched properly and not mixed, probably Xbase++ will put a reference to the control inside the itemData to don't mix events.

So, maybe not the most common way, but not a bug as it works like the documented behavior

About using non Xbase++ controls in the GUI thread, I always create them in the GUI thread and as child of a XbpStatic. It works pretty well and not cause conflicts with the existing Xbase++ parts.

>You have to accept the fact that
> the Xbase++ GUI was not built to allow and support "intruders".

This not mean that cannot be used any other stuff using the winapi directly, just that must be carefull to don't conflict with the existing Xbase++ stuff.

> I've tried to contact Pablo on this issue via private email
> because we're playing in his backyard here, but unfortuntaly I seem to
> have fallen prey to his spam filter.

uhhhmm, have review the bulk folder on my email accounts but have not found your email
can you send again to pb (AT) xbwin ( DOT) com ? 

Regards,
Pablo

Hello Pablo,
this is what I got yesterday after sending a second private mail to you:

--- snip ---
Reporting-MTA: dns;comparcomputer.com
Received-From-MTA: dns;DenkDeckel
Arrival-Date: Mon, 17 Oct 2011 17:53:45 +0200

Final-Recipient: rfc822;pb@xbwin.com
Action: delayed
Status: 4.4.7
Will-Retry-Until: Wed, 19 Oct 2011 17:53:45 +0200

--- snap ---
Best regards,
Michael

Hi,

I think probably not the right NG for this subject, if I not wrong a bug is when the stuff is not working as documented. In this case subclassing the drawingarea window proc is not an Xbase++ documented stuff. 

At any point ( I'm not sure if inside the drawingarea winproc or using a windows hook) Xbase++ dispatch the  WM_MEASUREITEM  and WM_DRAWITEM notifications and call to the corresponding :drawItem and :measureItem methods ( or codeblocks ) on the corresponding child Xbp.

If this not happening as documented, the you can report the bug here attaching a pure Xbase++ example prg as simple as possible showing the incorrect behavior, so the Alaska guys can determine if a bug or not and try to fix it.

But in this case, if the introduction of a new control directly using CreateWindowEx() is not handled as expected, maybe will be a subject for the wishcolector.

BTW: I'm using an XbpStatic as the parent all the time I need to add a control outside the Xbase++ box, so just need to subclass my XbpStatic to dispatch the notifications, and usually works well, just sometimes need to add extra handling usually performed by TranslateMessage() that not always called inside the GUI thread message loop.

Maybe you can try the sugestion from Michael and just try to use a different ID on your "native" controls, and in the subclased wndproc of the drawingarea dispatch only notifications corresponding to your controls and let the previous wndproc to do the handling on the other.

Regards,
Pablo

hi,

> Maybe you can try the sugestion from Michael and just try to use a 
> different ID on your "native" controls,

this is what i did, i do have a Constante APP_ID_LISTBOX <> 0

 INLINE METHOD My_MEASUREITEM(wp,lp)
...
    use _write()_ to made it "read" Member
   ::oMeasureitemstruct:_write_(lp,0,-1)

    use only "my" Control CtlID
    IF ::oMeasureitemstruct:CtlType = ODT_LISTBOX .AND. ;
        ::oMeasureitemstruct:CtlID   = APP_ID_LISTBOX


Xbase++ seems NOT to use CtlID, which is recommend (?),
so "pure" XbParts will not run any more with XBP_DRAW_OWNERADVANCED
and "fall back" to XBP_DRAW_OWNER

this happend when i use my "native" Control or other 3-PP Common Controls 
which use CreateWindowEx()

so my Question is : can this leak cause the Problem ... and what else ?

greetings by OHR
Jimmy

hi,

it seems not any more my "native" Control to make any Problem.

it is a "funny" BUG (?) in "pure" Xbase++ when try to "fill" 2 or more
Ownerdraw Listbox / ComboxBox in a seperate Procedure ?!

please look @next Thread "why cant i fill 2x Ownerdraw Listbox together ?"

thx for big Help to Michael and Pablo

 greetings by OGR
Jimmy