Hi,
The DBE and DBE's settings are lost when XbpHTMLWindow executes a
codeblock.
What am I missing?
(attached is a modified PRG of the SlidingList sample that illustrates
it).

BTW, what should I change to enable execution of the Expended
codeblock when an item is already expended (second click of the same
item)?

Many thanks,
-Itai

Itai,

>The DBE and DBE's settings are lost when XbpHTMLWindow executes a
>codeblock.

The settings aren't lost, but like all thread-local settings, they will be 
presenting the Xbase++ default values.

>What am I missing?

The reason for this is, that those callback slots are executed in the 
Xbase++ UI thread, in which all XbaseParts are created. The same is true for 
most owner drawing events, like: xbeP_Gesture, xbeP_Draw, xbeP_DrawItem, 
xbeP_CustomDrawCell, and xbeP_MeasureItem, etc.

This thread usually has the Thread ID number 2, but you can retrieve the 
actual Thread ID with the "UIThreadID() function during runtime.

Any code run in those callback slots in response to one of those events 
should be as fast and short as possible, as it otherwise might make the 
entire application unresponsive.

>BTW, what should I change to enable execution of the Expended
>codeblock when an item is already expended (second click of the same
>item)?

The Item's :Expanded codeblock is only called if an item is expanded, not 
when it is selected. The same is true for the :Collapsed codeblock, which is 
only executed when another item is expanded and the (current) item is 
actually being collapsed, and not when the item loses focus or something 
else receives focus. Those events are generated in the context of updates to 
the graphical representation, not in the context of selecting or activating 
elements, such as buttons, for example. 

But you can use the XbpHTMLElement:LbDown callback slot to react to a click 
on any of the HTML elements -- no matter if they are collapsed or expanded, 
or if they are even collapsible or expandable or not. Just keep in mind that 
the xbeM_LbDown event is generated in addition to (and after) the (user- 
defined) xbeP_ItemExpanded event, so you should ignore the xbeP_ItemExpanded 
and xbeP_ItemCollapsed events, if you are only interested in the selection 
of (or a mouse button click on) an element/item.

Also, because the mouse event callback slots are executed in the active 
thread, rather than the UI Thread, there aren't any issues with the DBE or 
any other Thread-local settings being invalid or missing.

Hope that helps,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas@AbsoluteSoftwareLLC.com
web:   http://www.AbsoluteSoftwareLLC.com
[L]:   https://www.LinkedIn.com/in/AndreasGehrsPahl
[F]:   https://www.FaceBook.com/AbsoluteSoftwareLLC

Thank you so much, Andreas!!
This is an important piece of knowledge.  I did not know that xBase
executes certain callbacks in separate threads.  Are there other
threads beside "main" thread and "UI" thread?
BTW, do you optimize the load of each thread or should I
programmatically optimize each one via SetLogicalProcessor()?

I will try the LbDown (IMO, it should be LbUp to maintain consistent
behavior with buttons).

It would be nice to add to XbpHTMLElement() a Status var indicating if
element is expendable or collapsible.  Moreover, it would be really
nice to add a Status() method so we can programmatically change the
status of an element.

Again, many thanks for your reply.
-Itai

Itai,

>This is an important piece of knowledge. I did not know that xBase
>executes certain callbacks in separate threads.

It's mostly the owner-drawn functionality that is executed in the UI thread, 
and most of those events are documented as such. Btw, it's "Xbase++", not 
"xBase", unless you want to poke the polar bear and invoke the wrath of 
Alaska's Frank++. It probably is one possible way to evoke a response from 
Alaska, though.

>Are there other threads beside "main" thread and "UI" thread?

Xbase++ runs at least three more threads, including the Garbage Collector 
(GC) thread, and of course you can run as many threads as you like (or at 
least as many as the OS can handle). If you look at the resource monitor, 
you will see that any Xbase++ program will run between 5 and 7 threads, even 
if you don't create any additional threads yourself.

>BTW, do you optimize the load of each thread or should I
>programmatically optimize each one via SetLogicalProcessor()?

SetLogicalProcessor() assigns ALL threads of an Xbase++ application to a 
specific (logical) processor, as all threads of an Xbase++ application must 
run on the same processor. Otherwise the required coordination overhead 
would slow down the program immensely. So you can't assign individual 
threads to processors or vice versa, anyway.

>I will try the LbDown (IMO, it should be LbUp to maintain consistent
>behavior with buttons).

LbClick and RbClick callback slots would probably be even better, but you 
have to use what Alaska provides, as the XbpHTMLElement() objects are 
created (and assigned) by XbpHTMLWindow() and other XbpHTMLElement() 
objects, so you can't even sub-class them to add additional functionality, 
which would have then to be connected to the HTMLayout ActiveX object's 
events and properties, anyway.

>It would be nice to add to XbpHTMLElement() a Status var indicating if
>element is expendable or collapsible. Moreover, it would be really
>nice to add a Status() method so we can programmatically change the
>status of an element.

You can always hope -- or petition Alaska -- but I don't think this will get 
you anything. HTMLayout has been discontinued for some time now, and has 
been replaced by Sciter. And (as far as I know), Alaska has planned to 
replace HTMLayout with something else -- probably Google Chromium-based -- 
for a long time now. It will probably be only a few more years or so. 

So, I don't expect Alaska to much expand on HTMLayout-specific functionality 
anymore, but of course, I could be wrong.

Hope that helps,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas@AbsoluteSoftwareLLC.com
web:   http://www.AbsoluteSoftwareLLC.com
[L]:   https://www.LinkedIn.com/in/AndreasGehrsPahl
[F]:   https://www.FaceBook.com/AbsoluteSoftwareLLC

Andreas,
One more question:
Can a window in each thread run as ShowModal() or only one window in
the entire application be set as ShowModal()?

Itai,

>Can a window in each thread run as ShowModal() or only one window in
>the entire application be set as ShowModal()?

As with all modal windows, that depends entirely on the specified 
Parent and Owner of the dialog. If the Owner is SetAppWindow() -- or 
XbpApplication():MainForm -- than all children of that dialog are disabled 
and the dialog is modal with respect to all dialogs that have SetAppWindow() 
(or XbpApplication():MainForm) as Parent and all their children, which could 
be the entire application. You can use AppDesktop() as Parent for any modal 
dialog, as AppDesktop() will never be disabled (by making a dialog modal).

Dialogs that have a different Parent than the modal dialog won't be 
disabled, so there could be several modal dialogs active at the same time. 
This is quite often the case in multi-threaded applications.

If the modal dialog is also a child of the Owner, the application would 
basically be locked, as the modal dialog would also be disabled. So, make 
sure that you specify a different Parent and Owner for all dialogs that you 
want to be modal by either using the :ShowModal() method or by manually 
setting the modal state by using the :SetModalState(XBP_DISP_APPMODAL) 
method. The :ShowModal() method won't actually set the modal state if Parent 
and Owner are the same, to prevent lockups.

Also, the :ShowModal() method is just a shortcut for manually setting the 
modal state by using :SetModalState(XBP_DISP_APPMODAL), running your own 
eventloop, and then using :SetModalState(XBP_DISP_MODELESS) to unlock all 
the other dialogs with the same Owner, when you are done.

And you can find the source code for :ShowModal() in the following file:

	...\Source\Runtime\DUI\XbParts.prg

Hope that helps,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas@AbsoluteSoftwareLLC.com
web:   http://www.AbsoluteSoftwareLLC.com
[L]:   https://www.LinkedIn.com/in/AndreasGehrsPahl
[F]:   https://www.FaceBook.com/AbsoluteSoftwareLLC

Andreas,
Please look at the entry above the modal.
Thanks,
-Itai