Re: Link error
On 15/05/2008, at 1:15 PM, Vivian Chen wrote: Would you help me if I have any question in future? I'm on this list so post here and I'll help if I can. -- Link -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
Re: Link error
On 14/05/2008, at 11:32 AM, Vivian Chen wrote: Thanks. I really know very little about the cygwin. How to link project to the cygwin? I think I have. Must I choose - mno-cygwin? If I choose, I get a undefined reference to error. -mno-cygwin means your app will not be linked to Cygwin. You should just leave that switch off to link to Cygwin. As you said, if I want to use POSIX APIs, I must do it. And If I won't, I needn't. Is it right? Yes... but you might not get to make that decision anyway since you're creating a .dll that some other app will load. If I want to link with -mno-cygwin, and won't get a undefined reference to error, how can I do? Why do you want to link with -mno-cygwin? Did you actually have a problem linking to Cygwin or are you guessing that you don't need it? When you talk about error messages you need to include the entire message or we're left guessing what the problem is. You say undefined reference to... to what? -- Link -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
Re: Link error
On 14/05/2008, at 7:54 PM, Vivian Chen wrote: Because my library has called some standard C library functions in it. And when I debug the project, there's a crash. As I've already said, without the actual error messages you're getting from the computer we can only guess what the problem is. Do you have some suggetions when use the standerd C library functions in Garnet? The short answer is don't do it. In Palm OS 68K API Documentation, it says that to use Palm OS functions rather than standard C library functions directly. ... But Palm OS functions are also based on standard C library functions. Are they? The Palm OS functions are not based on the standard C library. The standard C library is just an API that many systems provide. Palm OS does not provide the standard C library but it provides analogues for some of the functions. When you build an app for Palm OS and you use standard C library functions there are 2 things you need to be aware of. 1) The function must be available. The easiest way to ensure this is to link to a static libc. 2) The function must not use kernel calls that are not provided on Palm OS. Things like string handling can be done entirely in user space but thing like malloc rely on the kernel to do their work. If you are creating a .dll for the simulator then I'm pretty sure you must use the same standard C library that the simulator uses so you will need to confirm which one that is. It could be Cygwin, it could be the Windows C library (crt.dll) or even one of the newer Visual Studio libs (eg. msvcrt.dll). Getting a crash using standard C library functions could indicate that you are using a function that makes kernel calls or that your C library's structures have not been initialised properly (eg. because the process that loads your .dll was using a different libc). If you really want to use libc functions you would be better off implementing them yourself on top of the Palm OS APIs because then you would be sure that they will work identically in .dlls and as 68k or ARM code running on a device. -- Link -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
Re: Link error
On 13/05/2008, at 1:28 PM, Vivian Chen wrote: I've search from Google that -mno-cygwin mean to use mingw to compile not cygwin. And -nostdlib means not to use standard library. The second one is easily to be understood. But I'm quite confused to the first one. My library is compiled by gcc. What's the difference between mingw and cygwin? You have a Cygwin-based GCC. The -mno-cygwin lets it work like the MinGW compiler. This means you will not have the cygwin.dll dependency but it also means you won't have POSIX APIs, only what Windows gives you (ANSI C). If not choose -mno-cygwin, when I debug it , it would use Cygwin1.dll? No. Another thing, if I link without -mno-cygwin, it would works well in a PNO project (at least can startup). But if do, it would not startup in a Protein project. It would appear an error says SIGSEGV signal availabel: segmentation fault What's the problem? SIGSEGV signal ... is that meant to be unavailable? ANSI C has only a few signals (though SIGSEGV is one of them). If the hosting process (simulator) is using Cygwin and your code is not, the definition of SIGSEGV (and other, more important things) may be different. Try linking your Protein project to Cygwin. -- Link -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
Re: First defined here
On 17/04/2008, at 11:34 AM, Vivian Chen wrote: No, the error is just first defined here. And all the parameters are correct. I'm sure. Without seeing the whole error (exactly as it comes out of the compiler) or the header/source versions of the function it's impossible to guess at the cause. -- Link -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
Re: typedef struct _opaque *
On 16/04/2008, at 6:30 PM, Vivian.Chen wrote: As we know, we will use MemHandle while do the memory manage. It's defined into typedef struct _opaque *. What's the _opaque? I can't find it in any head files. What type is it? It's just a pointer. I wouldn't be surprised if it just points to the MemPtr it returns when you unlock it (though more likely the structure includes reference count info). The important function is that the handle can remain the same while the memory it points to is moved around (needed because there's no VM system to hide the memory fragmentation). ie. Handle (0x0001) - Ptr (0x1001) - data // data gets moved around by Palm OS Handle (0x0001) - Ptr (0x2001) - data And how about the MemPtr? Does it equal to void*? Yes, MemPtr is equivalent to void*. Just assign to the correct type. eg. MemHandle handle = MemHandleNew(sizeof(MyStruct)); MyStruct *foo = MemHandleLock(handle); // init foo MemHandleUnlock(handle); // Palm OS can move memory so the foo pointer might become invalid // Lock it again before using it foo = MemHandleLock(handle); // access foo MemHandleUnlock(handle); MemHandleFree(handle); -- Link -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
Re: First defined here
On 16/04/2008, at 6:56 PM, Vivian.Chen wrote: When I compile my program, it says that first defined here in a function. I've declear it in the .h, and implement it in .c. How this happen? You've left out part of the error message. The error is probably along the lines of: function takes args x, y but first defined here to take arguments x, y, z. Commonly caused by having a non-matching prototype. If you change the args or return type and don't update the prototype you'll get this error. -- Link -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
Treo modem/phone emulator?
I'm trying to write an app that responds to phone events (call connected, call released) but something seems to not be working. Since my phone calls aren't free I'd prefer to have some sort of modem/phone emulator that I can use to simulate phone calls (while ensuring that notifications and stuff are sent out as they are on a real Treo). I haven't tried them yet (because I haven't got a Windows environment handy) but it sounds like the Palm OS or Treo Simulators won't help me out here. Are there any other options? Thanks in advance. -- Link -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
Re: display value of variable?
On 14/03/2008, at 9:46 PM, Geetha Arasu wrote: Variable.. Declare it with a ptr... Char *cP; Not that way or you'll get a crash. StrPrintF needs an initialized pointer. Char cP[20]; Int num=6 StrPrintF(cP, %d, num)- %d is for integer ErrFatalDisplay(cP) This assumes your display string is less than 19 characters. There's no checking of the length though so make use your buffer is big enough for the string you're writing into it. -- Link -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
Re: How to lock a resource (and know it's locked later)?
On 13/03/2008, at 1:29 AM, Ben Combee wrote: So far so good... I figured I'd store the handle in the Saved Preferences so that I can get to it next time the app runs. This fails in a number of situations though (reboot, hotsync, recompile). Store the handle in a feature pointer. Those are cleared on system reset. Reset was easy to solve (I was already listening for the reset signal to re-enable the app). I've figured it out now. I'm not checking that the lock is valid but instead relying on app lifecycle to sort me out. Events like hotsync, reset and delete are how I make sure I don't end up with a stale handle (they had to be handled anyway to prevent crashes due to alarms/notificatinos). The recompile situation seems to be unique in that I can't seem to trap for it but then, regular users won't be rebuilding from source using OnBoardC. I could always write the version into the prefs and check for it (OnBoardC increments the version number every time it rebuilds) but I don't know if I'll bother. Thanks anyway guys. -- Link -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
How to lock a resource (and know it's locked later)?
Hi guys,
I was told this is the place to ask questions like this...
I'm using AlmSetProcAlarm() so that I can do something without waking
the device. Since I don't want my code to go and move I figured the
best solution was to lock the code resource. I ended up with this code:
DmOpen...
MemHandle h = DmGet1Resource('code', 1);
MemHandleLock(h);
DmRelease...
DmClose...
So far so good... I figured I'd store the handle in the Saved
Preferences so that I can get to it next time the app runs. This
fails in a number of situations though (reboot, hotsync, recompile).
The problem is that I can't find a way to verify that the resource is
still locked using public APIs. A utility I found called Palm
Internals shows when my app has locked the code resource so it's
clearly possible to do, perhaps only using private APIs though?
What about storing the pointer instead of the handle and calling
MemPtrRecoverHandle()?
I also thought about protecting the whole database but the docs for
DmDatabaseProtect() don't give me much confidence that I won't run
into similar problems. Will unprotecting too many times cause a crash?
Background (in case it helps).
I'm setting an alarm so I can beep/vibrate at determined intervals
(eg. every 2 minutes). This is for a utility that augments the
attention manager by continuously trying to get your attention until
you clear the attention items. If it helps, source (last released
version, not using AlmSetProcAlarm) can be found here: http://
ramsay.webhop.org/attngrab. Let me know if you'd like current source
(I use OnBoardC for development, getting code out is a non-trivial
exercise).
--
Link
--
For information on using the ACCESS Developer Forums, or to unsubscribe, please
see http://www.access-company.com/developers/forums/
