On 28 Sep 2008, at 22:26, Felipe Monteiro de Carvalho wrote:
APPKIT_EXTERN NSString *NSToolbarSpaceItemIdentifier;
How would it be possible to access them in Pascal?
var NSToolbarSpaceItemIdentifier: CFStringRef; external;
var NSToolbarSpaceItemIdentifier: CFStringRef; cvar; external;
(the
On 29 Sep 2008, at 16:04, EarMaster - Bent Olsen wrote:
I use Xcode to find samples of codes and try to make it work on FPC/
Lazarus.
One example opens an AUGraph and send MIDI messages - a small
sample. It
calls AUGraphNewNode which returns a node from 1 to n, and it works
perfectly in FPC
Hi all,
I use Xcode to find samples of codes and try to make it work on FPC/Lazarus.
One example opens an AUGraph and send MIDI messages - a small sample. It
calls AUGraphNewNode which returns a node from 1 to n, and it works
perfectly in FPC on Carbon/i386, and of course for Xcode on the same
mac
nope ... went back to the previous crash
--
Felipe Monteiro de Carvalho
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
wow! Changing the bundle name the stacktrace of the crash changes!
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0x40d42008
Thread 0 Crashed:
0 libobjc.A.dylib 0x90a5dc7e _cache_flush + 71
1 libobjc.A.dylib 0x90a5db04 flush_caches + 2
I have commented the code to the point where nothing is different from
similar projects, but the crash remains ... it's almost like Mac OS X
doesn't like my project, or it stored somewhere that this one won't be
allowed to run =) I even deleted the entire directory structure and
got fresh files fro
Hello,
I am getting a very strange crash, in a place of my code which never
hat problems before. The exact same code works in another PasCocoa
example, and even the same code worked before! Sometimes the
application won't crash, but most times it will. Here is my code (also
available in the lazaru
Graeme Geldenhuys wrote:
On Mon, Sep 29, 2008 at 11:19 AM, Brad Campbell <[EMAIL PROTECTED]> wrote:
I'm chasing an issue with a program I have that is leaving an Ansistring
unfreed on exit. It exists cleanly without using halt(), but this is the the
only way I've managed to reproduce it.
Should
> From: Florian Klaempfl
>
> I've only one arm box so I can't work well on oabi and eabi. My box
> still runs oabi (multi boot is not possible with the Thecus). If someone
> offers me reliable access to a fast >=500 MHz, >=128 MB eabi box, some
> GB HD, I'll fix the needed stuff.
>
Unfortunately I
On Mon, Sep 29, 2008 at 11:19 AM, Brad Campbell <[EMAIL PROTECTED]> wrote:
> I'm chasing an issue with a program I have that is leaving an Ansistring
> unfreed on exit. It exists cleanly without using halt(), but this is the the
> only way I've managed to reproduce it.
>
> Should Halt() leave memor
I'm chasing an issue with a program I have that is leaving an Ansistring unfreed on exit. It exists
cleanly without using halt(), but this is the the only way I've managed to reproduce it.
Should Halt() leave memory unfreed?
It is only reproducible if I use ExtractFileName or ExtractFileExt.. (
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:fpc-pascal-
> [EMAIL PROTECTED] On Behalf Of Jonas Maebe
> Sent: 29. september 2008 10:46
> To: FPC-Pascal users discussions
> Subject: Re: [fpc-pascal] Carbon: i386 vs PPC API's
>
> On 29 Sep 2008, at 09:27, EarMaster - Bent Olsen wro
On 29 Sep 2008, at 09:27, EarMaster - Bent Olsen wrote:
Is there any precautions one should make when sharing FPC codes
between i386
and PowerPC?
I've few calls to AudioToolbox API's which works fine under i386, but
crashes in PPC - the exact API call is AudioConverterNew, and the
records
Hi all,
Is there any precautions one should make when sharing FPC codes between i386
and PowerPC?
I've few calls to AudioToolbox API's which works fine under i386, but
crashes in PPC - the exact API call is AudioConverterNew, and the records
passed to the API looks good, and is also returned by A
14 matches
Mail list logo
