Loading ...
Sorry, an error occurred while loading the content.

Re: [peditors] more Fatal Alerts since last pToolSet update

Expand Messages
  • Paul Nevai
    HI Bill: # I have noticed that I seem to be getting more Fatal Alerts since I # installed pToolSet 6.63 (13 July 2003). The two I see most # frequently are: #
    Message 1 of 11 , Aug 1, 2003
    • 0 Attachment
      HI Bill:

      # I have noticed that I seem to be getting more Fatal Alerts since I
      # installed pToolSet 6.63 (13 July 2003). The two I see most
      # frequently are:
      #
      # MemoryMgr.c, Line: 4450, Invalid chunk ptr
      # NotifyMgr.c, Line: 2269, Stack overflow

      # This one is pretty repeatable, even after a soft reset. If it does
      # not happen the first time, it will often occur on the second or
      # third try. It appears to occur most often when initiating the search
      # from within DateBk4.

      #1. What OS?

      #2. I talk a lot about stacks in pedit's manual. Read about it and then fix
      it using the advice there. Search for the word "stack".The reason is that
      DateBk4 does not create a stack recommended by "modern" apps. This way it is
      compatible,with OS 1.0 and such. See also MemBrain.

      pedit even includes a stack increaser function but it does it for pedit only.

      Interestingly, I never saw a "NotifyMgr.c, Line: 2269, Stack overflow"
      myself.

      BTW, what are you doing with DateBk4 when there is DateBk5?

      Best regards, Paul
    • Paul Nevai
      # - press 123 to activate pMasterTool # - open pMagiPad # - type text string (within Palm Find length constraint) # - use button bar S to select all
      Message 2 of 11 , Aug 1, 2003
      • 0 Attachment
        # - press "123" to activate pMasterTool
        # - open pMagiPad
        # - type text string (within Palm Find length constraint)
        # - use button bar "S" to select all current text and copy to clipboard
        # - "OK" to exit magiPad
        # - click "Find" icon to activate pFindTool
        # - "123" to open pMasterTool over pFindTool
        # - "paste text" to pFindTool using pMasterTool menu

        BTW, this is the wrong way to do it. You could ccopy'n'paste directly from
        pMagiPad into pFindTool. BUT this is not a crash preventer. Just more
        efficient.

        click "Find" icon to activate pFindTool
        open pMagiPad
        type
        copy'n'paste [see the Edit menu]

        Best regards, Paul
      • W. B. Maguire II
        Paul: ... May I answer that for *myself*? ... I use an app. to manage the color scheme on my Visor Prism. Why? Because I *much* prefer to read and edit light
        Message 3 of 11 , Aug 1, 2003
        • 0 Attachment
          Paul:

          At 05:21 AM 8/1/03 -0400, you wrote:
          > :
          > :
          >BTW, what are you doing with DateBk4 when there is DateBk5?


          May I answer that for *myself*?

          -----BACKGROUND:-----

          I use an app. to manage the color scheme on my Visor Prism. Why? Because
          I *much* prefer to read and edit light text on a dark background (a sure
          sign of an old-time programmer! ;-) ), rather than the PalmOS default of
          black-on-white. In order to accomplish this personalization, I use a
          PalmOS application called "Butterfly" (highly recommended) (and "Khroma"
          before that, and "Chrome" before that,...). Butterfly is a very well-done
          program that allows me to change the color of 22 different components of
          the PalmOS, e.g. "Form Frame/Fill", "Dialog Frame/Fill", "Alert
          Frame/Fill", "Menu
          Frame/Fill/Foreground/Selected-Fill/Selected-Foreground", "Control
          Frame/Fill/Foreground/Selected-Fill/Selected-Foreground", and "Field
          Background/Text/Text-Lines/Caret/Text-Highlight-Background/Text-Highlight-Foreground".
          For instance---rather than removing them completely---I can change those
          annoying text-field dotted-lines into a nice blue on my black text-field
          background (still there but subtly in the background).

          Butterfly performs *flawlessly* with all applications that "play by the
          rules" when it comes to elements of their forms and coloring of such---like
          pedit and *every* other application on my Prism. Unfortunately, the DateBk
          author flushes the rules, as I'll discuss below.

          -----DATEBK ISSUE:-----

          Unfortunately, the guy who writes DateBk (CESD / Pimlico Software) knows
          better than *every* consumer, and decided that he must *force*
          (INCONSISTENTLY) the colorization of his application, rather than let the
          OS control it. In DateBk4 there were some problems, but I am able to live
          with them. For instance, I can't let DateBk4 control the alarms, because
          when the alarm screen shows, DateBk4 *forces* the background of the
          alarm-description text to be white (rather than using an OS-defined color
          like the "Text Background"), but did *not* force the foreground text to be
          black (he *did* use the OS color---"Text Foreground"---here). My
          colorization software---Khroma at the time---couldn't do anything about the
          forced-white background, but it *did* change the foreground text to
          white. The result: white text on a white background; real
          informative! >:-P Luckily, I'm able to *usually* get past this through
          the DateBk4 option of letting the built-in DateBook control the alarms
          (although that is a pain---in itself---for various reasons stated in the
          manual). Another similar---but less critical---example is the month view;
          DateBk4 *forces* the lines that make-up the calendar to be black (rather
          than choosing a more *intelligent*---not hard-coded---color! Like maybe
          the OS's foreground-text color?), but the background is the "Form Fill" (I
          believe) color which I have set to a dark navy blue (of course, this
          normally works great when all the foreground text/lines/etc. are a *light*
          color). The result: black lines on a dark navy-blue background. Not too
          clear. There are additional examples, but, like I said, I learned to live
          with these problems.

          Before resigning to just *living* with these problems, though, I contacted
          the author of DateBk4. In a sincerely *helpful* tone, I went into great
          detail (like this letter) about why *forcing* some colors to hard-coded
          values---rather than using one of the OS-determined palette values (that
          Butterfly could then change)---was a real problem for people with color
          devices who wanted to *customize* the interface of those devices. I
          mentioned that customization was probably a small audience now, but was
          *definitely* the way of the future! Just look at all those applications
          out there that have the (frequently useless) ability to change
          "skins". For God's sake, they're even starting to do it *electronically*
          for cell phone exteriors! I told him that Khroma (what I used at the time)
          was an *excellent* piece of freeware, and that this problem would just bite
          more and more Khroma+DateBk users in the future.

          This is---in its entirety---his response (of 31-Jan-2002):

          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          >IT is neither practical nor feasible for me to modify my program to
          >accomodate [sic] personal choices that you make for color schemes based
          >on some other third party program that is twiddling the system palette
          >underneath DateBK4.
          >
          >That may be subject to review at some later time, but it won't be made in
          >the forthcoming V-4.1/5.0. I will put it on the list of things to review in
          >the future.
          >
          >Cheers!
          >CESD, Pimlico Software, Inc.
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

          He obviously didn't really *read* my letter, because I clearly stated that
          we were not talking about unpractically catering to a tiny hacker audience,
          but rather---as Paul often puts it---PLAYING BY THE RULES. When a software
          author *plays by the rules*, it provides more flexibility for *other*
          software that may build upon the original author's product. Using DateBk's
          author's (il)logic, there is no need for a color palette at all! Palm
          should have asked *Pimlico* what 8 colors *they* wanted everyone to have
          (why bother with 65536 colors?), the PalmOS could support those 8 colors,
          and every application could hard-code the colors for every element of its
          interface. No worries about pesky personal choices, right? Oh wait, there
          *is* a reason that computers use a *palette* of colors, and programs then
          *reference* that palette, because that way is the *smart* way, not the
          *stupid* way!

          LapTopHack is an *exact* analogy for this issue! Any Palm app. that uses
          its own, custom, non-standard interface will *not* be able to be controlled
          by LTH. So, a short-sighted (polite for "nimrod") software author will
          make his fancy, pretty, non-standard picture-buttons to be tapped by a
          stylus, without the slightest inkling that this will render his product
          almost totally useless in a *keyboard* environment. Since that software
          doesn't play by the rules, LTH is prevented from working its
          brilliance! The DateBk products do *not* play by the rules, and they've
          become *worse* with each new version. As long as you prefer *all* of the
          pre-chosen colors of the DateBk interface, you're fine. If you get excited
          over a product like Khroma or Butterfly, thinking "Wow! I can make all the
          colors in my Palm applications be the way *I* want them! I can have
          off-white text on a dark-navy-blue background instead of black on white!",
          you'll be *very* disappointed to find out that DateBk ignores some of your
          choices---but not others---leading to a disastrous mess of colors and a
          totally illegible result.

          When I downloaded DateBk5 (for a trial before purchasing), everything
          looked *awful*! Pimlico forces the colors---inconsistently---on even
          *more* of the critical form elements in DateBk5 than in
          DateBk4! Really! The day-view (the most important for me!) was
          *completely* illegible! Random colors everywhere! Needless to say, I
          quickly reverted back to the only-semi-busted DateBk4. And that's the
          long-winded explanation for why *I* am forced to stick with the older DateBk4.

          Lastly, I have to say that with the advent of the Butterfly program, this
          color problem can be somewhat alleviated---although not to *my*
          liking. The author of Butterfly---wisely---saw that there was a very small
          population of programs/programmers that are viciously opposed to
          standardized color-palette use, and so he added the capability to turn
          *off* the palette manipulation for those 'nimrod' applications (that you
          choose from a list of all the programs on your Palm). This feature would
          allow me to use DateBk4 or DateBk5 using the *standard* Palm colors and the
          *specific* black-, red-, and blue-on-white colors that the DateBk author
          decreed for everyone. But I *hate* looking at that black (and blue and
          red) text on a bright white background; therefore I live with my color
          scheme and the less-busted DateBk4 over the completely-busted DateBk5. So,
          there *is* a solution with Butterfly, it's just not the *best*
          solution. The *best* solution is for DateBk's author to *use* the
          *feature* that is the OS color palette for form elements ... to *allow* you
          the freedom to customize your color palette ... to PLAY BY THE RULES!

          Bruce.

          --
          Yahoo-ized (stupid "`" place-keepers required) and
          Spam-resistant (replace "_at_" with "@") signature:

          ` _________ Maguire_at_AnalyticInvestments.com _____ |**===
          `/ ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` |**===
          (` W. B. Maguire II, Ph.D. `` Tel: 303.772.1615 `` ` |=====
          |` Chief Executive Manager `` FAX: 303.651.6389 `` 9||
          |` Analytic Investments LLC ` ` ` ` `_` ` ` ` ` ` ` ` ` ` |
          |` 700 Ken Pratt Blvd STE204 PMB166 ( ) The ASCII ribbon `|
          (` Longmont CO, 80501-6455 ` ` ` ` ` X ` campaign against )
          `\_________________________________ / \ _ HTML e-mail ___/
        • Bill Starr
          Thanks for your reply, Paul. 1) I have a Palm Vx with OS 3.5.3. 2) I m hoping that DateBk5 does not have this issue with the stack. 3) Until today, I had
          Message 4 of 11 , Aug 1, 2003
          • 0 Attachment
            Thanks for your reply, Paul.

            1) I have a Palm Vx with OS 3.5.3.

            2) I'm hoping that DateBk5 does not have this issue with the stack.

            3) Until today, I had resisted upgrading from the last version of
            DateBk4 due to the memory hit. I have been happy with the
            capabilitities, and only have about 10 percent of my 8M RAM free, so
            had wanted to avoid losing about 1/4 of my free space by upgrading.

            Today I bit the bullet and deleted some large app's and DOC files I
            rarely use. Then I updated to the last DateBk5 release. Even after
            the update, I now have about 13 percent free. So far no Fatal Alerts
            since updating, even when running through the typical scenario I had
            outlined.

            Regards, Bill


            *****
            Message 22238
            From: Paul Nevai <nevai@m...>
            Date: Fri Aug 1, 2003 4:21 am
            Subject: Re: [peditors] more Fatal Alerts since last pToolSet update

            #1. What OS?

            #2. I talk a lot about stacks in pedit's manual. Read about it and
            then fix it using the advice there. Search for the word "stack".The
            reason is that DateBk4 does not create a stack recommended
            by "modern" apps. This way it is compatible,with OS 1.0 and such.
            See also MemBrain.

            3) BTW, what are you doing with DateBk4 when there is DateBk5?


            *****
            Message 22237
            From: "Bill Starr" <bill.starr.yahoo@s...>
            Date: Thu Jul 31, 2003 9:17 pm
            Subject: more Fatal Alerts since last pToolSet update

            I have noticed that I seem to be getting more Fatal Alerts since I
            installed pToolSet 6.63 (13 July 2003). The two I see most
            frequently are:

            MemoryMgr.c, Line: 4450, Invalid chunk ptr
            NotifyMgr.c, Line: 2269, Stack overflow

            This one is pretty repeatable, even after a soft reset. If it does
            not happen the first time, it will often occur on the second or
            third try. It appears to occur most often when initiating the search
            from within DateBk4.
          • Paul Nevai
            # Today I bit the bullet and deleted some large app s and DOC files I # rarely use. Then I updated to the last DateBk5 release. Even after # the update, I now
            Message 5 of 11 , Aug 1, 2003
            • 0 Attachment
              # Today I bit the bullet and deleted some large app's and DOC files I
              # rarely use. Then I updated to the last DateBk5 release. Even after
              # the update, I now have about 13 percent free. So far no Fatal Alerts
              # since updating, even when running through the typical scenario I had
              # outlined.

              Actually, DateBk5 did not solve the stack problem. I never ever had problems
              with it though. I use it too. Take a look at TealMemBrain. Or fix the stack
              of DateBk5. It is easy to do with RsrcEdit. Copy pedit's stack pref resource
              to DateBk5. Look in the manual for "'pref' #0" resource.

              Best regards, Paul
            • Bill Starr
              I m not sure what you mean by wrong , unless you mean less- efficient. I was not aware (or had forgotten) that pMagiPad had this command. Thanks for pointing
              Message 6 of 11 , Aug 1, 2003
              • 0 Attachment
                I'm not sure what you mean by "wrong", unless you mean less-
                efficient.

                I was not aware (or had forgotten) that pMagiPad had this command.
                Thanks for pointing it out. I may try using it more often.

                I do almost everything by taps, rather than keyboard and / or
                graffiti. I think what I lose by using three taps to navigate to and
                select the Copy'N'Paste from the pMagiPad menu I make up for by not
                having to tap "OK" to exit pMagiPad, then "123" to activate
                pMasterTool, then one more tap to select Paste from my customized
                menu.


                *****
                Message 22239
                From: Paul Nevai <nevai@m...>
                Date: Fri Aug 1, 2003 4:24 am
                Subject: Re: [peditors] more Fatal Alerts since last pToolSet update

                # - press "123" to activate pMasterTool
                # - open pMagiPad
                # - type text string (within Palm Find length constraint)
                # - use button bar "S" to select all current text and copy to
                clipboard
                # - "OK" to exit magiPad
                # - click "Find" icon to activate pFindTool
                # - "123" to open pMasterTool over pFindTool
                # - "paste text" to pFindTool using pMasterTool menu

                BTW, this is the wrong way to do it. You could ccopy'n'paste
                directly from pMagiPad into pFindTool. BUT this is not a crash
                preventer. Just more efficient.

                click "Find" icon to activate pFindTool
                open pMagiPad
                type copy'n'paste [see the Edit menu]


                *****
                Message 22237
                From: "Bill Starr" <bill.starr.yahoo@s...>
                Date: Thu Jul 31, 2003 9:17 pm
                Subject: more Fatal Alerts since last pToolSet update

                The typical scenario for me is:

                - press "123" to activate pMasterTool
                - open pMagiPad
                - type text string (within Palm Find length constraint)
                - use button bar "S" to select all current text and copy to clipboard
                - "OK" to exit magiPad
                - click "Find" icon to activate pFindTool
                - "123" to open pMasterTool over pFindTool
                - "paste text" to pFindTool using pMasterTool menu
              • Paul Nevai
                # I do almost everything by taps, rather than keyboard and / or # graffiti. I think what I lose by using three taps to navigate to and # select the
                Message 7 of 11 , Aug 2, 2003
                • 0 Attachment
                  # I do almost everything by taps, rather than keyboard and / or
                  # graffiti. I think what I lose by using three taps to navigate to and
                  # select the Copy'N'Paste from the pMagiPad menu I make up for by not

                  No need to navigate to it: command-q or ESC q. Best regards, Paul

                  P.S. Should I assign "copy'n'paste" to a button-slided "P"?
                • Paul Nevai
                  # I m not sure what you mean by wrong , unless you mean less- efficient. Yep. /Paul
                  Message 8 of 11 , Aug 2, 2003
                  • 0 Attachment
                    # I'm not sure what you mean by "wrong", unless you mean less- efficient.

                    Yep. /Paul
                  • C. E. Steuart Dewar
                    ... The DateBk calendar program was written a couple of years before color devices appeared and even before hacks appeared. In the earliest versions of the OS,
                    Message 9 of 11 , Aug 2, 2003
                    • 0 Attachment
                      > Unfortunately, the guy who writes DateBk (CESD / Pimlico Software) knows
                      > better than *every* consumer, and decided that he must *force*
                      > (INCONSISTENTLY) the colorization of his application, rather than let the
                      > OS control it.

                      The DateBk calendar program was written a couple of years before color
                      devices appeared and even before hacks appeared. In the earliest versions of
                      the OS, everything was hard-wired, and so it was not unusual for third party
                      applications to be written on the assumption that things that were
                      hard-wired in the device were not likely to change. Of course, we all made
                      SOME accomodations for potential future changes, but when you originally
                      develop an application that has to run on a device with at best 512k of
                      memory, you have to be very parsimonious in including extra code on the
                      off-chance it might be needed in the future.

                      So this is not a case of intentionally sidestepping the standard color
                      scheme of the Palm OS. It was a matter of not having the available time to
                      spend several days of work sifting through 100,000 lines of code looking for
                      every single case where color is applied and adding the code to pull the
                      default color off the UIcolor table. At that time, I was dealing with core
                      functionality issues that affected ALL users of the application.

                      The Palm OS has the provision for setting the screen size, but if someone
                      wrote a hack to take over the bottom 20 pixels of the screen for a status
                      display and told the third party app the screen was actually 160x140, you
                      can be very sure that few (more likely none) third party applications would
                      be accomodating. Just because the Palm OS has a feature that is unused on a
                      standard device does not mean that every application has to fully implement
                      it on the off-chance that one day someone might write a hack that require
                      all apps to conform to that feature.

                      Everything has to do with priorities and the point was that those few days
                      of effort were far more important to devote to something that many hundreds
                      of thousands of users wanted rather than something that probably only
                      affects a few hundred (at most) users and then only at a cosmetic, not a
                      functional level.

                      I have on every release, caught more and more items. At this point, there
                      are very few (meaning none that have been recently drawn to my attention)
                      places left in the current V-5.1a release that do not conform to the
                      standard color palettes. I made it a higher priority in V-5.1a because of
                      the appearance of themes which depend upon that conformance for a consistent
                      display...

                      The comment that it has gotten worse is uninformed. And I will continue
                      to address any other places that are drawn to my attention.

                      As for the stack issue, I don't recollect what the minimum available stack
                      size was for DateBk4 while it was running, but my guess is that it was at
                      least 1,500 bytes (based on the fact that the larger and more complex
                      Datebk5 never left less than 2k bytes). However, in V-5.1a of DateBk5, I DID
                      increase the stack size by another 1k since there are more and more newer
                      hack writers who tend to lack parsimony in that area and for the end user, a
                      crash is a crash - regardless of how or why it was caused. Hack writers
                      should always use dynamic stack frames so they steal as little stack space
                      as possible from the applications running above (and most of the good hack
                      writers I know have been doing that for some time if they needed a lot of
                      local storage). DateBk4 & DateBk5 have always used dynamic stack frames in
                      all the alarm code for just that reason...

                      Cheers!
                      CESD, Pimlico Software, Inc.
                      ==========================================
                    • Bill Starr
                      That idea sounds wonderful, Paul. I ll be glad to try it out if you like. As I ve mentioned before, I seldom use my PPK since I found FitalyHack. Graffiti is
                      Message 10 of 11 , Aug 2, 2003
                      • 0 Attachment
                        That idea sounds wonderful, Paul. I'll be glad to try it out if you
                        like.

                        As I've mentioned before, I seldom use my PPK since I found
                        FitalyHack. Graffiti is fine occasionally, and I'm pretty proficient
                        at it, but I have had trouble with something akin to "graffiti
                        degradation" (Ref: following link) for nearly as long as I've had my
                        Palm Vx. I confirmed this with GrafAid. I tried to figure out what
                        causes it, but finally gave up and just found ways to accommodate,
                        including using Fitaly for almost all text entry.

                        http://www.geocities.com/SiliconValley/Campus/9054/tapbuga.html

                        Because of the "spurious straight diagonal lines [which] appear
                        instantaneously at the start of a Graffiti stroke", I can't count on
                        any particular graffiti stroke being accurate. This is merely
                        annoying when trying to produce accurate text. But when trying to
                        execute commands, as with a command stroke, or LTH or pedit or
                        pToolSet escape sequence, it can cause the loss of data, so I try to
                        do as much as I can with taps (or slides), since they are generally
                        more reliable for me.

                        Thanks, Bill


                        *****
                        Message 22248
                        From: Paul Nevai <nevai@m...>
                        Date: Sat Aug 2, 2003 6:19 am
                        Subject: Re: [peditors] Re: more Fatal Alerts since last pToolSet
                        update

                        No need to navigate to it: command-q or ESC q. Best regards, Paul

                        P.S. Should I assign "copy'n'paste" to a button-slided "P"?


                        *****
                        Message 22247
                        From: "Bill Starr" <bill.starr.yahoo@s...>
                        Date: Fri Aug 1, 2003 9:49 pm
                        Subject: Re: more Fatal Alerts since last pToolSet update

                        I do almost everything by taps, rather than keyboard and / or
                        graffiti. I think what I lose by using three taps to navigate to and
                        select the Copy'N'Paste from the pMagiPad menu...
                      Your message has been successfully submitted and would be delivered to recipients shortly.