Previous Thread
Next Thread
Print Thread
984.2 #29709 13 Mar 07 04:56 AM
Joined: Jun 2001
Posts: 11,645
J
Jack McGregor Online Content OP
Member
OP Online Content
Member
J
Joined: Jun 2001
Posts: 11,645
Although 5.0 has been fairly stable, we managed to accumulate another 12 patches over the last few days, which can be downloaded from the main www.microsabio.com 5.0 download page.

The devnotes can be accessed directly (as text) at:
http://www.microsabio.net/dist/50rel/ashdevnotes.txt
or as CHM on the main documentation page.

I know that "12 patches" and "stable release" don't fit well into the same sentence, but they all seem fairly harmless (i.e. fix problems that are unambiguous even if obscure, without being likely to cause much ripple.) Nevertheless, I intend to wait a few days to see if there is any fallout before posting full release packages.

Re: 984.2 #29710 16 Mar 07 07:02 AM
Joined: Sep 2002
Posts: 5,450
F
Frank Online Content
Member
Online Content
Member
F
Joined: Sep 2002
Posts: 5,450
UGH!!

Just downloaded this patch...

All of my xtree displays are double spaced!!!! (Jack, see the main menu for example)

Oddly, the editable grids are fine...

Wonder whay nobody else has sqealed about this yet... confused

Re: 984.2 #29711 16 Mar 07 07:27 AM
Joined: Sep 2003
Posts: 4,135
Steve - Caliq Offline
Member
Offline
Member
Joined: Sep 2003
Posts: 4,135
laugh Mine were too..and I went around fixing them all, as we did not code according to the documentation. wink

See release note:
Quote

4.
---
XTREE fix/enhancement: In a tree with editable cells and fixed height
rows, the row height is (and has been) set to the height needed to display
an edit or combo box control. In other cases (variable height rows or
no editable cells), the row height is typically less. This has caused
unhappiness from various parties, for two reasons:

a) In the case of editable cells with variable height rows
(XTF_VARY + XTF_EDITABLE), the rows start out short but then change height
when a cell is edited on that row. (I've argued that this is a "feature"
not a bug, but with decidedly poor results.)

b) In the case of non-editable trees with fixed height rows, the row
height doesn't match the equivalent tree with editable cells. (This is
hard to label a "feature", but it is debatable whether it is a bug.)

To "fix" these "problems" without breaking existing properly-written programs,
XTREE now allows you to set XTR'ITEMLINES to 0, producing the same effect
as 1 except that the row height in both of the above cases will be set to
match the edit/combo control height (in other words, to match the height
of editable trees with fixed height rows).

Warning: there is a slight compatibility concern here. Even though the
effect of setting XTR'ITEMLINES=0 was not previously defined, in practice,
it acted like XTR'ITEMLINES=1. The XTREE row height in such programs may
be increased when installing this patch. (Although we try to avoid this
kind of situation, especially in the "stable" release, in this case, the
change is subtle enough, and purely aesthetic, and only affecting programs
that were not coded according to the documentation, that it seemed harmless.)


Re: 984.2 #29712 16 Mar 07 08:39 AM
Joined: Sep 2002
Posts: 5,450
F
Frank Online Content
Member
Online Content
Member
F
Joined: Sep 2002
Posts: 5,450
Hmmm... i did read that initially, and we just leave itemlines=0, so i had hoped there would be no additional problems.

We have tons of xtree calls... im not really ready, willing or able to cycle thru every program and fix/retest... hence the so-called stable release that nobody seems to find the value in??? eek

I have been flexible in making changes to accomodate 5.0 requirements, but in this case, i need an ashell change to revert back to the original xtree handling.

Thanks.

FWIW:

In addition, i find offense to the caveat:

"and only affecting programs that were not coded according to the documentation, that it seemed harmless". I submit that the documentation is dubious at best as it relates to this field... as well as the idea of an editable cell wasn't even a figment in Jorge's head at the time some of us were knee deep in xtree... why not make the switch=2 to to achieve the desired behaviour, as oppose to changing existing 3+ year old behavior?

Re: 984.2 #29713 16 Mar 07 08:55 AM
Joined: Sep 2003
Posts: 4,135
Steve - Caliq Offline
Member
Offline
Member
Joined: Sep 2003
Posts: 4,135
You mean all your XTREE code is not in just one INCLUDE or SBX! (and can be over ridden in the program if needed) :rolleyes: Lucky mine was, and I just recompiled a dozen or so programs after a one line change.

But I know what you mean, as I thought it was just me not coded according to the documentation. wink

Have a fun weekend everyone.... cool

Re: 984.2 #29714 16 Mar 07 02:04 PM
Joined: Jun 2001
Posts: 11,645
J
Jack McGregor Online Content OP
Member
OP Online Content
Member
J
Joined: Jun 2001
Posts: 11,645
Well, I guess it's a good thing I've been sitting on 984.3 all week, as perhaps we can settle this muddle along with all of the other things pending in 984.3.

I'll admit that the documentation isn't perhaps as clear as I was imagining. It says that xtr'itemlines is "Maximium number lines of text displaying in a cell. If flags XTF_VARY not set, affects all rows." Taken literally, zero would mean that the maximum number of lines displaying in each cell was zero, but obviously that was not the case.

Changing the special flag to have the row height match the height needed for editable cells from 0 to 2 doesn't work, because that really would mean to doublespace. (Currently, what you are getting with xtr'itemlines=0 is more like 1.5 spacing, although that would be determined by the desktop font metrics which affect the size of combo boxes.)

I had originally considered using -1 (i.e. 255) but then thought that it might introduce it's own degree of confusion, but perhaps on second thought, it would be a better idea. (Particularly since I doubt that anyone is currently taking advantage of whatever might currently happen if you set xtr'itemlines=-1.)

So, if there are no objections, in 984.3, I'll put xtr'itemlines=0 back the way it was, and anyone who wants the row height to match that needed for editable cells can set xtr'itemlines=-1.

Re: 984.2 #29715 16 Mar 07 02:28 PM
Joined: Sep 2002
Posts: 5,450
F
Frank Online Content
Member
Online Content
Member
F
Joined: Sep 2002
Posts: 5,450
Muchas gracias, Senor...

Have a good weekend.


Moderated by  Jack McGregor, Ty Griffin 

Powered by UBB.threads™ PHP Forum Software 7.7.3