Page 18 of 33 FirstFirst ... 8131415161718192021222328 ... LastLast
Results 341 to 360 of 657
  1. #341  
    0.9b5 should solve this problem.
  2. #342  
    Hope you got my email. The FEED problem turning to 1E1D with hold L->O->U:e->1->E setting comes from conflict with re-enable after reset and text plus. A possible workaround to this is to delay the re enable of keycaps. Can you put a configurable option as to how many seconds after soft reset before it re-enables?
  3. #343  
    I have temporarilyworked around the problem by disabling the re-enable after a reset feature in keycaps.(enable is highlighted after a reset when it should be disabled!)

    Its a hassle to enable this manually after a soft reset then launch and exit Butler just so key launch would work.
  4. #344  
    Everything's hooking the same event, and it can become a real mess with ordering. There's really not much I can do about it; if I change KeyCaps to work around the problems with TextPlus, it'll break Butler.

    You may be able to get a suitable ordering by deleting and reinstalling applications. I'm not sure.
  5. #345  
    It works when keycaps is activated manually after textplus has activated itself automatically after a reset. If you can make keycaps activate after textplus has then problem would be solved. But Butler may be affected. Hmmm... there should be a solution to this problem.
  6. wpwoodjr's Avatar
    Posts
    94 Posts
    Global Posts
    203 Global Posts
    #346  
    Quote Originally Posted by MFB
    Its a panl application patched by doomsey to lower cpu overhead. From my experience , it works well with most apps except for Blazer when a fully loaded page is necessary before it can "jump". With it active in Blazer, it can also cause a crash while moving fast between web links using treokeyhack or keycaps increased speed. I just disabled scrolljump in Blazer and all is well with keycaps.
    I'm sorry, I'm still confused - where do you get scrolljump from? Is it a utility for mapping the volume keys on the Treo or ?
  7. #347  
    Please do a search on this thread so you will find the info you need. Scrolljump is an application that let's you "jump" to the top and bottom of the page by pressing option up or down.

    doomsey,

    TreoKeyHack works well with textplus. I have moved keycaps to sd via powerrun. Butler still detects key caps so I still get keycaps functionality. I'm looking forward to Butler's update and keycaps release thereafter.

    Igor,

    Using hold L->O->U:e->1->E on p doesn't display P. I get stuck in the brightness panel. To workaround this, I'm forced to use double click upper E.
  8. #348  
    I'm a little bit surprised that TreoKeyHack doesn't have the same problems with TextPlus, since as a side effect of being a "hack" it doesn't see the events until after the notifications have all been processed. KeyCaps has trouble with TextPlus when it gets notifications after TextPlus got them.

    In any event, I can't really duplicate the position TreoKeyHack takes in the event handling chain without making KeyCaps itself a hack, so for now you're stuck with either TKH or the unfortunate necessity of manually enabling KeyCaps and Butler to get the event handlers in the right order.
  9. #349  
    The hold L->O->U:e->1->E problem is the same for both. However, double click is intermittently interfered by textplus with keycaps while treokey is unaffected. Disabling text plus stopped the double click problem with keycaps.

    I want to address the problem to the developer of textplus. How do I best explain it to them?
  10. #350  
    wait. I believe that 0.9b5 (and by extension 0.9b6, which fixes the disabled-but-says-enabled bug) fixed the broken L-O-U for P. Is this not the case?

    As for what to say to the TextPlus authors, a specific change that they can make which will solve the KeyCaps compatibility problem is use of a priority greater than zero when they register for the SysNotifyEventDequeuedEvent notification. If they did this, there would be no compatibility issue with KeyCaps and textplus.

    However, this isn't really necessary, since once the Butler issues are resolved, I'll be able to have KeyCaps always ask to go first (as keyshades does), resolving the TextPlus problems.
  11. #351  
    Yes, it did fix it with textplus but k launch didnt work with Butler anymore. (as expected)

    I havent heard anything from hobbyistsoftware regarding the k launch fix he will be implementing soon. I hope it doesnt take too long.

    Thanks again for helping doomsey : )
  12. #352  
    MFB: see http://mytreo.net/forum/index.php/topic,17923.15.html in which Rob states he's working on a version of Butler that solves the KeyCaps bugs.
  13. #353  
    Oh, I posted there too! Any inside info when Rob will be releasing it?
  14. #354  
    Just thought I'd chip in here. Generally speaking, benchmarks are fun but the real world is where it's at. However, this hede/hvch thing has made a huge difference on my 600. I eliminated SoundOff (for now at least), upgraded to the newest (non-hede-using) KeyGuard+, and patched the TreoAllegro binary to use hvch (works great) - no more hedes here. My PI speed test score went from ~350 seconds to ~4 seconds. Immediately I could see performancement improvements in general responsiveness, in TCPMP and Live! (faster), Table Tennis 3D and GTS Racing (smoother). Mapopolis (GPS) seemed to get to the turns quicker as well. But the biggest change was in Bike or Die - it went from slo-mo to real-time, a completely different experience. Maybe I'll go back and try some of those games and apps that just seemed way too slow before.

    So, thanks to the posters in this thread and to Igor for PI - my Treo experience is now even better.
  15. #355  
    can you or someone post the patched treo allegro? thanks!

    PS - 1st post from my treo!
  16. aldamon's Avatar
    Posts
    650 Posts
    Global Posts
    684 Global Posts
       #356  
    Quote Originally Posted by rollo
    So, thanks to the posters in this thread and to Igor for PI - my Treo experience is now even better.

  17. #357  
    I'm also benefited from this thread. Now I'm happy with some games that I thought it was too slow for my Treo. Thanks so much!!
  18. #358  
    All,

    I just wanted to provide some information on the practice of call backs and other address registering programming techniques on the Treo 650. I just got this information from a source at PalmSource. This is the company that develops the operating system on the Treo's and other palm devices.

    I quote from an forum thread at PalmSource:

    If your application isn't running, and isn't in the ROM, then you
    probably shouldn't use AlmSetProcAlarm. That routine takes a pointer
    to your function, so it is your duty to make sure your code will
    always be at the location you gave. That's easy while you're
    running, but when you quit, there's a lot of things you need to start
    to worry about:
    - you have to prevent the user from deleting your database (that's
    the DmDatabaseProtect bit)
    - you have to prevent the memory chunk from moving in memory (in 5.x
    you could usually do this by keeping the code resource locked, but
    there are issues which could arise e.g. with NVFS systems unless they
    hacked around that.)
    - you have to implement some way to unregister & unprotect your app
    so the user can delete it (in the obviously unlikely case that they
    don't want your fine software any more)
    - there are probably other pitfalls that don't come to mind right now

    In short, it is much easier to use a launch code if you're not
    running, and besides, you don't really gain much by going the
    ProcAlarm route anyway, unless you're a part of the ROM.

    -David Fedor
    PalmSource, Inc.

    While it is true that David references ProcAlarms, the same address limitation exists with CallBack functions. He is basically saying that any function that relies on address consistency when running in the background is not safe on NVFS filesystems.

    A while back I gave an opinion but when I saw this information, I thought I should share it with this thread.

    Jeff

  19. #359  
    In short, it is much easier to use a launch code if you're not
    running, and besides, you don't really gain much by going the
    ProcAlarm route anyway, unless you're a part of the ROM.
    but i have gained in performance


    you have to prevent the memory chunk from moving in memory (in 5.x
    you could usually do this by keeping the code resource locked, but
    there are issues which could arise e.g. with NVFS systems unless they
    hacked around that.)
    There are already issues with the NVFS system, hence the scramble to make it work better with apps

    i have tested a couple of apps that use a new workaround for hede and they have improved my phones performance and stability. Just my 2cents
    Wisdom sheds light on the knowledge you have accumulated

    Palm Pre (Sprint)
  20. #360  
    Interesting. Thanks for forwarding that, Jeff.

Posting Permissions