Re: Code Warrior problem with XP updates
I have the same trouble. Only god know what is the service on your computer conflicts with CW93. So if you will reinstall Windows XP you resolve this problem in any cases. Of caurse you can try to switch off some services (antivirusses for example) but it may not be usefull for you. I resolve this problem for me by using the virtual machine with a clean Windows XP. - Original Message - From: danny wong To: Palm Developer Forum Sent: Wednesday, January 30, 2008 8:01 PM Subject: Code Warrior problem with XP updates Recently i had to reinstall XP and CW 9. Now everytime XP does a update CW will crash. This happens when i try to open a project via the menu or click on the folder icon. it also crashes when i try to change project path. anyone have this problem? i have tried updating CW to 9.3 and the problem is the same. the only way to fix this is uninstall CW and reinstall. just a pain in the butt. -- -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/ -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
Re: Palm OS Plumbing: Key and Pen flushes don't flush
Using the progress manager is the right way to go - definitely.
But if anyone wants a quick solution to a situation like this, just use
Aaron's FIX#2: Put these lines in whenever you want to throw away your pen
events (best placed, as mentioned by Aaron, in the beginning of a for loop).
do
{
EvtGetEvent(&evt, 0);
} while(evt.eType != nilEvent);
That will throw away all the pen and key events that occur during your
operation.
Thanks guys for helping a junior plumber out :)
2008/1/31, Lionscribe <[EMAIL PROTECTED]>:
>
> You shouldn't be using FrmDispatchEvent.
> That bypasses the que, & shouldn't be used by other than the
> eventHandlser.
> Use EvtEnqueEvent! That should que it after the pen events.
> Lionscribe
>
> Jonathan Carse wrote:
> >EventType evt;
> >evt.eType = frmCloseEvent;
> >evt.data.frmClose.formId = FrmGetFormId(tmp);
> >FrmDispatchEvent(&evt); // Dispatch close event. The should be handled by
> >the handler after all the pendowns, but somehow doesn't
>
> --
> For information on using the ACCESS Developer Forums, or to unsubscribe,
> please see http://www.access-company.com/developers/forums/
>
--
For information on using the ACCESS Developer Forums, or to unsubscribe, please
see http://www.access-company.com/developers/forums/
Re: Palm OS Plumbing: Key and Pen flushes don't flush
You shouldn't be using FrmDispatchEvent. That bypasses the que, & shouldn't be used by other than the eventHandlser. Use EvtEnqueEvent! That should que it after the pen events. Lionscribe Jonathan Carse wrote: >EventType evt; >evt.eType = frmCloseEvent; >evt.data.frmClose.formId = FrmGetFormId(tmp); >FrmDispatchEvent(&evt); // Dispatch close event. The should be handled by >the handler after all the pendowns, but somehow doesn't -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
Code Warrior problem with XP updates
Recently i had to reinstall XP and CW 9. Now everytime XP does a update CW will crash. This happens when i try to open a project via the menu or click on the folder icon. it also crashes when i try to change project path. anyone have this problem? i have tried updating CW to 9.3 and the problem is the same. the only way to fix this is uninstall CW and reinstall. just a pain in the butt. _ -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
Re: WinSetCoordinateSystem
At 03:15 AM 1/30/2008, you wrote: Subject: WinSetCoordinateSystem From: "Diana Tang" <[EMAIL PROTECTED]> Date: Tue, 29 Jan 2008 12:31:22 -0500 X-Message-Number: 11 I used WinSetCoordinateSystem(kCoordinatesDouble) in my program and it squished all my forms to the top left corner. I want to keep using 320 x 320. How do i expand all those forms? The gadget you mentioned earlier should be 160*160 because this will be handled by the OS in "standard coordinates" and fit nicely on the 320*320 screen. You need to be switching in and out of double density coordinates immediately before and after drawing so the system is always left using standard coordinates. // set double density coordinates // Draw stuff that requires double density coordinates // restore standard coordinates Roger Stringer Marietta Systems, Inc. (www.rf-tp.com) -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
Re: Palm OS Plumbing: Key and Pen flushes don't flush
At 03:15 AM 1/30/2008, you wrote: Subject: Re: Palm OS Plumbing: Key and Pen flushes don't flush From: "Jonathan Carse" <[EMAIL PROTECTED]> Date: Wed, 30 Jan 2008 16:22:48 +1300 X-Message-Number: 22 I've been at it all day, and nothing works. Here is my latest attempt: USE...THE...PROGRESS...MANAGER to drive your "long operation" The basic problem is your "long operation" isn't servicing the event queue, and it must be taking s long the users are thinking the unit has locked up. This is exactly what it exists for! Roger Stringer Marietta Systems, Inc. (www.rf-tp.com) -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
Re: Using Simulator to debug serial data
That sounds a lot simpler than trying to get Bluetooth working on Simulator! Bear with me while I get this right ;) - so you plug your serial cable (I presume it is a RS232 multi connector like this one -> www.serialio.com/products/cables/PalmMulti_RS232.php ?) into the Palm and the serial end into the PC. I don't use CW but I presume that you use the Simulator to run your app on and point CW at the Simulator and then step through your code examining the data coming in with CW? Regards Edward Jones Luc Le Blanc wrote: Edward Jones wrote: have you ever got a Bluetooth adapter to work with the Simulator? AFAIK the Simulator does not support Bluetooth at all. When I had to debug Bluetooth stuff in my app I just connected a real T3 to the CW 9.3 debugger with a serial cable (but I'm told it should work under USB too) so that I could step in my app running in the T3. Luc Le Blanc -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
Re: API to extract VFS filename from full path
FYI: here are my routines; (try to re-use what i can) :P
// look for a specific character in the memory buffer, starting at end
char *
_MemRChr(void *p, char chr, uint32 count)
{
char *pos;
char *x;
int i;
// default return value
pos = NULL;
// pre-condition (cannot have null pointer)
if ((p != NULL) && (count != 0))
{
// use temporary variables for processing
x = (char *)p;
x += count;
// lets scan the memory buffer
i = count;
do
{
if (*x == chr) { pos = x; break; }
x--;
} while (--i);
}
return pos;
}
and...
char *
_StrRChr(char *s, char chr)
{
return (char *)_StrNRChr((void *)s, chr, _StrLen(s));
}
char *
_StrNRChr(char *s, char chr, uint32 count)
{
return (char *)_MemRChr((void *)s, chr, (uint32)(MIN(count, _StrLen(s;
}
--
For information on using the ACCESS Developer Forums, or to unsubscribe, please
see http://www.access-company.com/developers/forums/
Re: API to extract VFS filename from full path
On Jan 29, 2008 10:46 PM, Luc Le Blanc <[EMAIL PROTECTED]> wrote: > > On Jan 29, 2008 6:00 PM, Luc Le Blanc <[EMAIL PROTECTED]> wrote: > > > Is there an API to extract the VFS filename from a fully > > > qualified name that includes the path? > > > filename = StrRChr(path, '/'); > > if (filename != NULL) filename++; > > > basic string routines? not sure if thats what your looking for; > > but thats how i would do something like that. > > Yep. From scratch. I just thought VFS had such things. > BTW, StrRchr doesn't exist. I have to write it too ;) strrchr? :) stdlib? anyhow. i think you've solved the problem now anyhow. now that i think about it; i knew i wrote my own string routines for a reason; there are a bunch of routines missing from the standard SDK that should be in a standard C library. -- // Aaron Ardiri -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
Re: Palm OS Plumbing: Key and Pen flushes don't flush
On Jan 29, 2008 1:14 AM, Jonathan Carse <[EMAIL PROTECTED]> wrote:
> I thought I won't have to deal with plumbing issues if I chose to be a
> software engineer... :)
:) actually - your issue is not a plumbing issue, its more a design flaw.
> I am performing a long operation in one of my functions, which takes about
> 30 seconds.
see; thats your problem. palm is not a multi-threaded operating system
so what happens is your routine takes over the device and when the
user taps on keys or pens, the interrupts for those input devices are
called which is eventually overflowing your buffer.
FIX #1:
the simple fix is to keep what you have; and, ensure the event queue
does not get full. instead of calling EvtFlushXXXQueue() after your
process; do it within in; after every iteration.
you need to prevent the event queue from getting full.
the problem with this approach is that there may be enqueued
events which you are going to lose/zap by calling flush()
FIX #2:
turn your for-loop into a series of nilEvent processing. ie: make the
processing event driven. when the process is running; simply ignore
all key and pen events - your busy :)
you can also do some form of animation/user interfaction every time
a nilEvent comes; like, show a percentage bar etc.. just locking up the
device is not acceptable; and, i'm not surprised the users clicking
around like crazy - your app locks up :) (in their eyes)
> // Iterate through all the databases (while there were no errors)
> for(u_wCurrentDB = 0; u_wCurrentDB < TOTAL_DATABASES && returnValue ==
> PERFORM_BACKUP_SUCCESS; u_wCurrentDB++)
> {
> // Long operation (backing up to memory card)
// Flush all user input out of the queues
EvtFlushKeyQueue();
EvtFlushPenQueue();
> }
instead.. if your looking for the lazy fix. i mean lazy when i say it;
as you should really restructure your code. lockups are expected
on windows mobile :) not on palm.
--
// Aaron Ardiri
--
For information on using the ACCESS Developer Forums, or to unsubscribe, please
see http://www.access-company.com/developers/forums/
