Plua onboard Memo Edit not saving work.

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Plua onboard Memo Edit not saving work.

Pal-3
Marcio,

While SrcEdit works well, I would mention somewhere in your documentation the "Memo Edit"
portion of your software does not "save" anything written between soft resets. I lost hours of
work this weekend unaware of this problem.

But I am not upset. I refuse to look a gift horse in the mouth, and PLua is a wonderful gift.



Thank you,
Pal

Reply | Threaded
Open this post in threaded view
|

Re: Plua onboard Memo Edit not saving work.

migueletto-2
--- In [hidden email], "Pal" <greenchile505@...> wrote:

> While SrcEdit works well, I would mention somewhere in your
documentation the "Memo Edit"
> portion of your software does not "save" anything written between
soft resets. I lost hours of
> work this weekend unaware of this problem.

Plua saves the memo only when you select "Done". I do not think a
reset is likely to happen *while* editing a memo, but I will add a
note about this anyway.

Regards,
Marcio.

Reply | Threaded
Open this post in threaded view
|

Re: Plua onboard Memo Edit not saving work.

Pal-3
Marcio,

You are correct, Plua does save the memo if "Done" is tapped. (I always tap Done so I can
tap Run) But it's the CONTENTS of the memo that is gone following a soft reset.

That is what was so strange. A new memo is created but any source code written
disappears following a soft reset. I can repeat this over and over on my TX.

I have switched to DOC, so it's not a problem for me, but I liked your simple, built-in
editor.


Regards,
Pal



--- In [hidden email], "migueletto" <migueletto@...> wrote:

> Plua saves the memo only when you select "Done". I do not think a
> reset is likely to happen *while* editing a memo, but I will add a
> note about this anyway.
>
> Regards,
> Marcio.



Reply | Threaded
Open this post in threaded view
|

Re: Plua onboard Memo Edit not saving work.

tleedenton2002
Pal,

      Yes, I can repeat the same thing.  I'm Glad I found your post or
I'd doubt myself.  I can even cut and paste the source code into a
memo, but if I edit it, the edits are lost after a soft reset and only
the cut and pasted version remains.

Dinnty



--- In [hidden email], "Pal" <greenchile505@...> wrote:
>
> Marcio,
>
> You are correct, Plua does save the memo if "Done" is tapped. (I
always tap Done so I can
> tap Run) But it's the CONTENTS of the memo that is gone following a
soft reset.
>
> That is what was so strange. A new memo is created but any source
code written
> disappears following a soft reset. I can repeat this over and over
on my TX.
>
> I have switched to DOC, so it's not a problem for me, but I liked
your simple, built-in

> editor.
>
>
> Regards,
> Pal
>
>
>
> --- In [hidden email], "migueletto" <migueletto@> wrote:
>
> > Plua saves the memo only when you select "Done". I do not think a
> > reset is likely to happen *while* editing a memo, but I will add a
> > note about this anyway.
> >
> > Regards,
> > Marcio.
>


Reply | Threaded
Open this post in threaded view
|

RE: Re: Plua onboard Memo Edit not saving work.

Kagehi

Noticed this myself, when my TX died and I had to move everything
over to my LifeDrive I got to replace it. The problem exists in "any"
application that used the memo database to store. Since I haven't
fiddled much with Plua, the main thing I had been working with was
something written for SmallBASIC, which also saves "its" files into
the memo database. Was I figured out, looking through all the
stuff stored in the backup archives, is that when you use Memo, it
automatically stored any changes made to its DB as you make
them. It seems that other "secondary" application update an "in
memory" copy of the DB, which is never properly saved, since
the Memo application never actually updates it. If you go into the
normal Memo app, then open the file, and just pop from their back
to something else, even without clicking "done", it saves the data
in the *permanent* copy. If you don't do that, then a soft reset
wipes the unsaved memory copy of the DB, then reloads from the
older copy, which didn't contain your changes, when you try to open
it again.

I look forward to some day when one of these companies come up
with a Palm style device, which isn't Windows based, that uses a
real OS, and doesn't have these screwball shortcuts and quirks. Oh,
and which isn't also a $%$%$ phone (since my job doesn't let me
carry one of those on the sales floor). The TX and Life Drive are both
pains in the ass, and I can't imagine the new ones being any better,
given they have to be compatible with the earlier ones (to some
extent). This is just another example of a compromise made for the
sake of speed, which only fracks things up when you try to do
something "different" than what they expected (which was for every
application to have its own DB, and none of them share anything).

________________________________
To: [hidden email]
From: [hidden email]
Date: Sun, 11 Nov 2007 18:39:59 +0000
Subject: [plua] Re: Plua onboard Memo Edit not saving work.


Pal,

Yes, I can repeat the same thing. I'm Glad I found your post or
I'd doubt myself. I can even cut and paste the source code into a
memo, but if I edit it, the edits are lost after a soft reset and only
the cut and pasted version remains.

Dinnty
_________________________________________________________________
Climb to the top of the charts!  Play Star Shuffle:  the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct
Reply | Threaded
Open this post in threaded view
|

Re: Plua onboard Memo Edit not saving work.

migueletto-2
Hi,

--- In [hidden email], Patrick Elliott <shadowfyr55@...> wrote:

> The problem exists in "any"
> application that used the memo database to store.
...
> Was I figured out, looking through all the
> stuff stored in the backup archives, is that when you use Memo, it
> automatically stored any changes made to its DB as you make
> them. It seems that other "secondary" application update an "in
> memory" copy of the DB, which is never properly saved, since
> the Memo application never actually updates it.

It seems that under PalmOS 5 using the DataMgr API's to write to a
database is not enough when it comes to the Address, Calendar, Todo
and Memo applications (and possibly others).

In practice this prevents third-party applications from modifying
these databases, which is a good or bad thing, depending on your point
of view..

Regards,
Marcio.

Reply | Threaded
Open this post in threaded view
|

RE: Re: Plua onboard Memo Edit not saving work.

Blake Winton-3
I could have sworn I read something a long time ago about how editting
the MemoDB wouldn't propagate the changes to the shadow MemoDB.

Paul, do you remember anything like that?  pEdit obviously works on
the PalmOS 5 devices, did you have to do anything special for it?
Flush the database somehow, or something?

Thanks,
Blake.

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of migueletto
> Sent: November 14, 2007 7:07 AM
> To: [hidden email]
> Subject: [plua] Re: Plua onboard Memo Edit not saving work.
>
> Hi,
>
> --- In [hidden email], Patrick Elliott <shadowfyr55@...> wrote:
>
> > The problem exists in "any"
> > application that used the memo database to store.
> ...
> > Was I figured out, looking through all the stuff stored in
> the backup
> > archives, is that when you use Memo, it automatically stored any
> > changes made to its DB as you make them. It seems that other
> > "secondary" application update an "in memory" copy of the
> DB, which is
> > never properly saved, since the Memo application never actually
> > updates it.
>
> It seems that under PalmOS 5 using the DataMgr API's to write
> to a database is not enough when it comes to the Address,
> Calendar, Todo and Memo applications (and possibly others).
>
> In practice this prevents third-party applications from
> modifying these databases, which is a good or bad thing,
> depending on your point of view..
>
> Regards,
> Marcio.
Reply | Threaded
Open this post in threaded view
|

Re: Plua onboard Memo Edit not saving work.

Pal-3
--- In [hidden email], "Blake Winton" <blake@...> wrote:

> Paul, do you remember anything like that?  pEdit obviously works on
> the PalmOS 5 devices, did you have to do anything special for it?
> Flush the database somehow, or something?

I do not recall.

At this point I believe it is futile to code Plua using Palm memos (MemoDB). "DOC" is better
due to lack of limitations. Essentially, I like Marcio's little built in, integrated editor. Marcio
probably woke up one day and thought "I could add this cool editor to Plua.prc" and he
did. But due to Palm OS quirks it didn't work out..

(Maybe the built-in memo editor should be removed; but that is none of my business).

If Marcio's built-in editor could edit DOC files, that would be great, but I think it might
take too much work to implement. So SrcEdit.prc is a suitable and capable alternative. I
can not complain.


Regards,
Pal

Reply | Threaded
Open this post in threaded view
|

RE: Re: Plua onboard Memo Edit not saving work.

Blake Winton-3
> > Paul, do you remember anything like that?  pEdit obviously works on
> > the PalmOS 5 devices, did you have to do anything special for it?
> > Flush the database somehow, or something?
> I do not recall.

Sorry about that, I meant Paul Nevai, author of pEdit, whom I copied on
the email.  His response was:
> > > In OS 5 pedit edits directly the OS 5 version of the DB.
> > Could you tell us what the OS 5 version of the DB is?
> > Or is that a trade secret?  ;)
> It's public but I don't have the stuff with me.
> Googlable: Memos-PMem.pdb

So, there you go.

> If Marcio's built-in editor could edit DOC files, that would
> be great, but I think it might take too much work to
> implement. So SrcEdit.prc is a suitable and capable
> alternative. I can not complain.

Mmm, SrcEdit...  :)  I did some work on that a while ago.  It was nice.

Later,
Blake.
Reply | Threaded
Open this post in threaded view
|

RE: Re: Plua onboard Memo Edit not saving work.

Kagehi
In reply to this post by migueletto-2

> It seems that under PalmOS 5 using the DataMgr API's to write to a
> database is not enough when it comes to the Address, Calendar, Todo
> and Memo applications (and possibly others).
>
> In practice this prevents third-party applications from modifying
> these databases, which is a good or bad thing, depending on your point
> of view..

Yeah, that would explain it. I had the same issue on the TX, which I think
uses 5. Was reading about this with respect to some other issue recently. Its
a side effect of some sort of change they made, and the effect is not unlike
if you did the same thing on a PC if you where to open the same text file in
SciTE and Notepad, changed it in SciTE, saved it, then went back and saved
from Notepad too. Wham! There go the changes.

Its hard to say for sure it that is what is going on, or it notices that its open,
changes that, but then doesn't save it back to the original. I do know that
the you have two copies when hotsyncing, one is the "live" version and one
the archive/backup or something. One will contain the changes, but the other
won't, and its **not** the one you expect/want that contains the changes.
I had to open them in SciTE and hand copy out the code, back into the Palm,
to recover what I was doing. :p

Best bet would be to either change things so we are not using the current
DB at all (may make it so you can open one from there, but it auto transfers
the document to the new DB, for compatibility), or give up using the internal
editor at all. Well, that or wait for Palm to release an OS that works like a
normal fracking OS when handling files. That or you could install Linux on it...
http://hackndev.com/releases  lol

Though, I understand that **other** bugs in the bloody Palm can hang it
during a reset, which kind seems to me to be a potential problem for using
the Linux system.
_________________________________________________________________
Peek-a-boo FREE Tricks & Treats for You!
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us