There is an advantage to storing the resize data in resources rather than in
an array, namely that one can then distribute alternate skins that include
not only new form layouts but also new ways for forms to resize, and
moreover it's easier for clever endusers to make changes to stuff
in a separa
My implementation is also cleanroom - we had major problems using the PDF
documentation by itself (the DIA resize down then automatically resizing
back problem).
Our slogan is "Re-inventing the wheel, every time" for a good reason. ;)
- Matthew Bevan
--
For information on using the P
> I have a similar product (uses a static array vs. application resource,
> but I'll be adding resource support now that you've mentioned it) in the
> works which will be released under it's own dual-license. Free for
> non-commercial use, licence required otherwise.
> The DIA support, however,
I have a similar product (uses a static array vs. application resource, but
I'll be adding resource support now that you've mentioned it) in the works
which will be released under it's own dual-license. Free for non-commercial
use, licence required otherwise. The DIA support, however, is only a m
A while back I asked if there was any GPL-compatible DIA support code that
could be used in place of CollapseUtils. I ended up writing my own,
compatible with Sony OS4, Sony OS5, Palm DIA and Handera (the last with a
bit more work perhaps). The code lets you describe the resize via data in
specia
