News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

MIP_SETPROPERROR?

Started by HSE, March 20, 2016, 01:44:59 AM

Previous topic - Next topic

HSE

Hi Biterider!!

Do You remember what means this error?

Object ID = 280 (Graph2d), Error Code = 536871252 (MIP_SETPROPERROR: SetProp failed)
Object ID = 810 (Grafico), Error Code = 536871252 (MIP_SETPROPERROR: SetProp failed)
Object ID = 170 (Integ01), Error Code = 536871252 (MIP_SETPROPERROR: SetProp failed)

Apparently Graph2d (2005) predate the debug system. And leaks memory every other line ( also predate Resguard).

Thanks. HSE

LATER: very interesting, in the not really working-demo implementation there is no leaks. Only one fixed memory allocation is made free correctly. Any errors either.

A couple of years later: The project can work with AsmC.
Equations in Assembly: SmplMath

Biterider

Hi HSE
The problem seems to be in the MsgInterceptor.Init method which seems to have a problem setting the window property (SetProp). Check the parameters of the API call to see what is going wrong.

Regards, Biterider

HSE

I found a very elemental problem  :icon_redface:

I convert the pointed object in an embeded object, and I don't erase the iniatilization. Apparently double  initialization was the error.

Thanks. HSE 
Equations in Assembly: SmplMath

Biterider

Hi
Embedding the object only reserves space on the host object, but doesn't set this property. In fact, if you are intitializing somehow twice, you can get this error. I would suggest to set a breakpoint in the MsgInterceptor.Init method and trace from where the call comes. In most cases there is something wrong with the invokation logic.

Biterider

HSE

Good clue  :t.

Initialization work well when using MakeObjects for MsgInterceptor, the problem is when using LoadObjects. I see now that demo07 use MakeObjects, (surely isn't related at all to pointed/embeded) .

I note this issue in some objects that create windows, obviously the same is true for objects that manage windows handles.

Thanks. HSE
Equations in Assembly: SmplMath

Biterider

Hi
THe difference between MakeObjects & LoadObjects is that the first compiles the code, while the second loads the compiled library to speedup the overall compilation process.
If you have changed something in the source code and you haven't compiled the object, you have always to use MakeObjects.

Biterider

HSE

I begin to make libraries when I'm begin to use SmplMath, because in that way You have less macro levels. 

The fact is I can't make libraries with objects that create windows. Perhaps some "addr" issue in general and perhaps $Methodaddr in particular.

Of course, here "issue" means "I don't know" or, how Hutch say, "there is a feature I don't understand"  :biggrin:

Equations in Assembly: SmplMath

Biterider

Hi
macro level is indeed a very restrictive limitation of ml.
I want to understand a bit more what you mean with the "addr" issue and why you can't create the object libraries.

Biterider

HSE

#8
Hi Biterider!

You can try to make a library from GridW.asm, for example.

The addr thing surely is my error, but you can see why is different making or loading MsgInterceptor.

Of course I will try to understand a little better what happen, but essentially all is working.

To compile the project is needed a modified compiler. JWasm13b in theory support 1600 bytes lines and 320 macro nesting levels. (the only collision is ".for", I think).

HSE

A day later: the problem with libraries apparently is some kind of recurrency in StaticMethod macro (used as StaticMethod Startup), libraries that work correctly never call StaticMethod.
Equations in Assembly: SmplMath

HSE

#9
The new HJWAsm32 without .for collision (replaced by .forh )


Also .switch, .case,.default,.endswitch have additional "h"
Equations in Assembly: SmplMath

HSE

What other thing could be than a foolish error?  :biggrin:

The Ancestor (window) was not included and, because StaticMethod trigger a recurrency in that case, never show what the error is.

Interestling, all the similar main modules I make are copies of the same base file, then look like a systemic problem. :dazzled:


Equations in Assembly: SmplMath

Biterider

Hi hse
I'm not at home for the next 2 weeks. I'll look into your  issue when i'm back.
Biterider

HSE

Hi Biterider!

I found it's a problem related with HJWASM. With ML the error detection work:...
.\Grid\GridW.inc(23) : error A2052: forced error : Undefined ancestor: Window
BuildInheritancePath(2): Macro Called From
  Object(36): Macro Called From
   .\Grid\GridW.inc(23): Include File
.\Grid\GridW.inc(59) : error A2052: forced error : Undefined method: GridW.WndProc
$MethodAddr(6): Macro Called From
  m2m(0): Macro Called From
   .\Grid\GridW.inc(59): Include File
.\Grid\GridW.inc(88) : error A2052: forced error : Undefined ancestor object: Window
ACall(24): Macro Called From
  .\Grid\GridW.inc(88): Include File
.\Grid\GridW.inc(116) : error A2052: forced error : Undefined ancestor object: Window
ACall(24): Macro Called From
  .\Grid\GridW.inc(116): Include File
...
Equations in Assembly: SmplMath

Biterider

Hi HSE
Glad to hear you found the issue.

Biterider

HSE

Hi Biterider!

Yes, a very elemental  error :icon_redface:

What I not found is the cause of error detection differences between HJWAsm and ML. Any clue?

ML also trigger recurrency.

Thanks. HSE
Equations in Assembly: SmplMath