At 09:36 AM 5/6/2004, you wrote:
Thanks for the note. I've upgraded pilrc to 3.2b1 -- it generates a
viewer.rcp.s file identical to pilrc 3.0 though... I didn't think to do a
cmp with the .ro files (if that would even be meaningful).
What is the viewer.rcp.s file? I don't see how PilRC can
From: Ben Combee [EMAIL PROTECTED]
What is the viewer.rcp.s file?
It's produced by a combination of cpp and my doaddition.pl script that does
addition within wordlist resources.
Alex
___
plucker-dev mailing list
[EMAIL PROTECTED]
On Tue, 04 May 2004, Ben Combee wrote:
You really should be using pilrc 3.1 or 3.2 beta -- the 3.0 version has
problems with auto control sizing and also doesn't set some control
attributes correctly.
Well, I finally got back to a machine I could sync to and tried a new
version compiled (in
the toolbar but before any page text
is drawn. If the toolbar is disabled in the prefs (ie. while on the
library form) then the mainform will render successfully. There still
seems to be a leak though(?), as toggling the DIA a few times will soon
lead to crash.
FWIW, the error dialog reads:
MemoryMgr.c
page text
is drawn. If the toolbar is disabled in the prefs (ie. while on the
library form) then the mainform will render successfully. There still
seems to be a leak though(?), as toggling the DIA a few times will soon
lead to crash.
Send me a copy of your viewer.rcp.s file.
Alex
--
Dr
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 endusers to the stuff in a separate resources.
And,
Sent to wrong list. Sorry.
--
Dr. Alexander R. Pruss || e-mail: [EMAIL PROTECTED]
Philosophy Department || online papers and home page:
Georgetown University || www.georgetown.edu/faculty/ap85
Washington, DC 20057||
U.S.A. ||
The compile problems are fixed.
Alex
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
---Reply to mail from Alexander R. Pruss about DIA code committed
The compile problems are fixed.
Whatta guy! Thanks!
---End reply
Christopher R. Hawks
HAWKSoft
-
Let's call it an accidental feature.
-- Larry Wall
I've committed the DIA code.
This has consequences for all developers who modify or create forms. Many
forms now come with resize descriptions in viewer.rcp.in. If you modify a
form, you need to make sure that the resize description for the form is also
modified. Things will crash
Getting the DIA behavior consistent across all forms by producing resize
info where appropriate is something that I would like people to help me
with.
One slightly-off-topic question... should we continue to call this
DIA in our codebase, when it is a new, homegrown reimplementation
From: David A. Desrosiers [EMAIL PROTECTED]
Getting the DIA behavior consistent across all forms by producing resize
info where appropriate is something that I would like people to help me
with.
One slightly-off-topic question... should we continue to call this
DIA in our codebase, when
page you
get when you click on a resized image that a full/larger image exists
for (and can be scrolled). It seems the form that pops up goes back to
the 320x320 size (DIA shown), but still thinks it has the full screen.
So depending on the rotation, it cuts off on the right or the bottom
. If
you remove the FrmDrawForm() call from LibraryFormInit(), it works (but of
course buttons don't get drawn). Strangely enough, with DIA minimized,
calling FrmDrawForm() in the library form (not in other forms, it looks
like) causes DIA to get maximized. Any ideas?
Alex
Hi,
Great to see that DIA is now implemented! I was working on a patched
solution for it, but now that there is a clean solution, I'm happy. Some
points, though:
1) About the problem with the Library form... I had the same problem
in my
own solution; I fixed it by calling
Too fast ;) I'll grab tomorrow's build as I don't have a compile
environment setup.
Thanks!
--Wes
Alexander R. Pruss wrote:
I just grabbed the 12:06 build from today, and while not 100%, is a
major step forward for compatability with my T3. The Library form could
use support for the
Fullscreenform works now. ARP
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
---Reply to mail from James Watkins-Harvey about DIA code committed
3) The snapshot source version (17h and 18h) seems to not compile when
--disable-palm-dia is passed to configure.
No, it doesn't. The problems are (mostly) with the #defines in resize.h
SaveResizePrefs() takes 3
Ok, all liked fine until I rotate the screen in the library form from
portrait to landscape and then back to portrait with the DIA/Silk
minimized.
I got: StringMgr.c, Lin:72, NULL string passed
And for once the Reset button worked.
I then tried to reproduce the error. I rotate with the silk
it errored). I then loaded Plucker
again, clicked on the folder icon to get the library form, hid the silk,
rotate the screen (using the dia controls). First from portriat to
landscape and then to portriat. Same Error. (Screen is blank)
After I reset it again, I played some more. Started
the screen (using the dia controls). First from portriat to
landscape and then to portriat. Same Error. (Screen is blank)
After I reset it again, I played some more. Started it with the library
form active and rotate it with the silk visible, When back to portrait,
hid the silk, same error
Well, I've got full DIA support in PalmBible+. Now it's time to do it in
Plucker. Given that people have been asking for Palm DIA support for half a
year, any chance the support could make it into HEAD despite the feature
freeze? The amount of changes to the code will actually be pretty small
On Tue, Apr 13, 2004, Alexander R. Pruss wrote:
Well, I've got full DIA support in PalmBible+. Now it's time to do it in
Plucker. Given that people have been asking for Palm DIA support for half a
year, any chance the support could make it into HEAD despite the feature
freeze?
Sure
to work just right is a big nuisance because to do it best I may
have to distinguish between a real win{Exit,Enter}Event and a fake one that
occurs when DIA is resized. I could do it by looking at the winEnter and
winExit values, but I would have to access the inside of the structures to
check
It sounds, then, that my method will still be compatible with cobalt and
will be easy to adapt to working with it more natively. So I guess I'll
implement it, first for PB+, and then for Plucker.
Alex
___
plucker-dev mailing list
[EMAIL PROTECTED]
I have, however, been thinking about a generalized way of doing DIA that
might even be better than using CollapseUtils. For each object on each
form, we set a bunch of possible attributes.
The DIA shipping on the T3 (codenamed Hawkeye) changed again in
Cobalt (6.x). I would only
At 05:52 PM 4/8/2004, you wrote:
I have, however, been thinking about a generalized way of doing DIA that
might even be better than using CollapseUtils. For each object on each
form, we set a bunch of possible attributes.
The DIA shipping on the T3 (codenamed Hawkeye) changed again
object-code
only, with a reference to where the source code can be found.
(2) They want developers to register, so that they can brag about large
numbers, and maybe send you marketing stuff.
I suspect that the number of people who want to use the DIA but don't want
to register and don't need
They have nothing to lose. After all, if they say no, we can just do a
clean-room rewrite--it's a tiny piece of code.
In my experience, if you offer to do a cleanroom rewrite from the
start, there is no incentive for them to cooperate and provide a dual
license or relicensing
29 matches
Mail list logo
