From: Geoff Schaller on
Mario.

Unfortunately this too is useless - plus you have a compound line that
makes your job harder. You have two 'API' type functions here: StrFile()
and getOSInfo() - I suspect you do not have debug info turned on inside
these because the error stack seems to stop with this line. So to narrow
is down you need something like this:

Debugoutput(cFile, iDOSError, iFError)
cDosInfo := GetOSInfo(iDosError,iFError)
DebugOutput("OS Info", cDosInfo)
StrFile(cFile,cDOSInfo+CRLF)

Now you will know which function is at fault and next, you will have to
step into it.

Geoff



"Mario Schulz" <info(a)removethiswegenspamconcept-dv.de> wrote in message
news:i2m54r$t9l$1(a)online.de:

> hi Geoff,
>
> sorry maybe to much code ?
>
> StrFile( cFile, GetOsInfo(iDosError, iFError) +CRLF) <== line18
>
> but i only wish an explain what that error code mean... i thought all
> ptr belongs to dynmic memory (g) ... or not ?
>
> bye,
> Mario

From: Mario Schulz on
Hi Geoff,

thank�s ... i now the compound line... i will do so as you suggested but
first i only what to know what this error means ? ...

bye,
Mario


From: Malcolm Gray on
On 27/07/2010 08:13, Mario Schulz wrote:
> hi,
>
> i recive such this error :
>
> GenCode 1 -> Argument error
> SubSystem -> BASE
> FuncSym -> REGISTERKID FuncPtr 0x00000000
> VO-Description -> PTR belongs to Dynamic Memory
> FError 0 = Successful completion
> Arg -> 0x04E2C384 -> 0x00000000Calling Stack :
> 00: 18 - McpErrorHandler - MCPWRITELOGFILE
> 01: 132 - McpErrorHandler - MCPERRORHANDLER
> 02: 2 - Predefined IconPushbuttons - OKPUSHBUTTON:INIT
> 03: 53 - Start - STARTOperating system :
>
>
> can someone tell me whats wrong ?

I think, but am not sure having not seen this for a long time,
that registerkid is complaing that you/someone have passed it a pointer
to a piece of dynamic memory and it cannot registerkid dynamic memory.

I am not really clear how you call stack is setup - I suspect the error
is at line 2 of Predefined IconPushbuttons - OKPUSHBUTTON:INIT
and the rest of the call stack is actually showing the error being
logged (I don't know your error handler so I don't know whether that is
a normal call stack)
From: Geoff Schaller on
Mario.

Like Malcolm speculates... but until we get to the offending line of
code, we don't know.

Geoff



"Mario Schulz" <info(a)removethiswegenspamconcept-dv.de> wrote in message
news:i2oor8$b89$2(a)online.de:

> Hi Geoff,
>
> thank�s ... i now the compound line... i will do so as you suggested but
> first i only what to know what this error means ? ...
>
> bye,
> Mario