subbes (subbes) wrote in ljdotnet,
subbes
subbes
ljdotnet

Feature Request

I use sema, and I'm very happy with it. But just today, something happened that made me realise there's a problem with the way it handles being unable to connect ot the server and post a message, and something I'd like my next client to definiteyl not do..

I was posting in a community journal and got the "this journal is in read-only mode", so I clicked okay and tried again (bad me, overloading the server). It went through, and I checked only to see that when I clicked "okay", sema had set the active journal back to my default but left the rest of the jourrnal entry as it was when I tried to post -- so I'd posted a community entry into my own journal.

This seems to be due to the "change back to default uder after post" setting. I'd really prefer if, after a _failed_ sttempt to post, the journal didn't set itself back to default user, but left _everything_ as it was when I attempted to post.

Cheers.
  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

  • 4 comments
Good point! The regular windows client - and I would guess Sema's, but, I don't know, has an even more irritating trait, which I got bitten by last night:

1. Post something.
2. Realize it's incomplete, haul it up, edit, add a paragraph.
3. Save.
4. Journal in read-only mode!
5. Oops. The edit box, with your changes, just closed. Um.
That was one of the really big mistakes visions made with it.
SharpJournal won't do this. :)
C# and .NET in general has a very powerful exception handling system. SharpJournal is written so that any major operation is embedded within a "try" block. If an error occurs, it stops doing the operation and displays an error message. This makes it very easy to avoid these bugs by including all steps of the operation inside the "try" block. If one step fails (such as sending the post to the server), none of the other steps are performed (such as clearing the subject/entry boxes and resetting the journal to use to your own).

So in short, SharpJournal won't have this problem.