Hi Przemek, Many many thanks for your great explanation.
In fact my main purpose was not to 'get into' HVM internals but just that function. I am working on something related to catch 'ERROR HANDLER' method of a class in C and, thus, I needed __GETMESSAGE functionality. Again, many thanks. José Luis Capel JLC>-----Mensaje original----- JLC>De: harbour-boun...@harbour-project.org [mailto:harbour- JLC>boun...@harbour-project.org] En nombre de Przemyslaw Czerpak JLC>Enviado el: miércoles, 17 de diciembre de 2008 14:54 JLC>Para: Harbour Project Main Developer List. JLC>Asunto: [Harbour] Re: OT: __GETMESSAGE JLC> JLC>Hi Jose, JLC> JLC>> Sorry for the off-topic and sorry for my low C level... JLC>> I saw that __GETMESSAGE in classes.c is defined as: JLC>> HB_FUNC( __GETMESSAGE ) JLC>> { JLC>> hb_retc( hb_stackItem(hb_stackBaseItem()- JLC>>item.asSymbol.stackstate->lBaseItem )->item.asSymbol.value->szName JLC>); JLC>> } JLC>> Then, in my proyect I want to integrate that piece of code. I do JLC>this: JLC>> #pragma BEGINDUMP JLC>> #include "hbapi.h" JLC>> #include "hbstack.h" JLC>> HB_FUNC ( __MYFUNCTION ) JLC>> { JLC>> char * cMessage = (hb_stackItem( hb_stackBaseItem()- JLC>>item.asSymbol.stackstate->lBaseItem )->item.asSymbol.value->szName) JLC>; JLC>> /* My code will go below */ JLC>> } JLC>> #pragma ENDDUMP JLC>> But when compiling this little example I have these messages error: JLC>> tdatabase.c JLC>> tdatabase.prg(220) : error C2223: left of '->item' must point to JLC>struct/union JLC>> tdatabase.prg(220) : error C2198: 'hb_stackItem' : too few actual JLC>parameters JLC>> tdatabase.prg(220) : error C2223: left of '->item' must point to JLC>struct/union JLC>> And this is my problem: I cannot understand these errors and also JLC>I cannot understand why in classes.c compile OK whilst in my project JLC>throws these errors. JLC>> If someone could light me I shall appreciate too much. JLC> JLC>In Harbour internal HVM structures are not public. It's done JLC>intentionally JLC>because we want to be free in farther Harbour developing and adding JLC>new JLC>extensions with problems with backward binary compatibility with 3-rd JLC>party code. It's very important issue and how big problems it can JLC>create JLC>you can see in xHarbour where even simple fix in structures used by JLC>profiler breaks binary compatibility and people cannot use existing JLC>FWH JLC>binaries. Hiding internal structures also resolves the problem with JLC>alignment so you do not have to ask 3-rd party developers to use JLC>exactly JLC>the same alignment as you when they compile code for libraries. JLC>So developers creating code for Harbour should use only public JLC>Harbour API JLC>and accessing item internals like in your above example is bad JLC>practice JLC>and we strongly suggest to not make anything like that. JLC>Anyhow we cannot stop you or anyone else and forbid it. This is only JLC>our JLC>suggestion and if you want you can ignore it but in such case you JLC>will JLC>have to accept that if we change sth in HVM internals then you will JLC>have JLC>to follow this changes and update your code to respect them or at JLC>least JLC>recompile it. JLC>So if your real want to unblock access to HVM internals for your code JLC>then it's enough to include hbvmint.h before any other harbour header JLC>files (please do not use hbvmopt.h as Teo suggested because this file JLC>will force creating separated binaries for MT and ST HVM). JLC>Please only remember that it will not work for #pragma BEGINDUMP JLC>because JLC>in final .c file the sections inside BEGINDUMP/ENDDUMP are included JLC>_AFTER_ JLC>harbour header files used for generated PCODE so #include "hbvmint.h" JLC>will JLC>not be the 1-st included harbour header file. It can be used only in JLC>separated .c files or you can edit manually .c file generated by JLC>Harbour JLC>compiler and add #include "hbvmint.h" at beginning. JLC> JLC>But I strongly suggest to use only documented Harbour API and change JLC>your JLC>code to work without "hbvmint.h", f.e.; JLC> JLC>/********************************/ JLC>proc main() JLC> ? __MYFUNCTION() JLC>return JLC> JLC>#pragma begindump JLC>#include "hbapiitm.h" JLC>#include "hbstack.h" JLC>HB_FUNC ( __MYFUNCTION ) JLC>{ JLC> long lOffset = hb_stackBaseProcOffset( 1 ); JLC> const char * cMessage = hb_itemGetSymbol( hb_stackItem( lOffset ) JLC>)->szName; JLC> JLC> hb_retc( cMessage ); JLC>} JLC>#pragma enddump JLC>/********************************/ JLC> JLC>If there is sth important for developers what cannot be done using JLC>public JLC>harbour API then please inform us. We will add new public functions JLC>or we JLC>explain why some internal structures should not be accessible by user JLC>code. JLC>But I do no think you will find many of such things. In Harbour only JLC>HVM lib JLC>needs it and rest of code (with the exception to emulation of some JLC>low level JLC>xHarbour HVM behavior in XHB lib) do not use it at all so it's JLC>possible to JLC>write code without it. JLC> JLC>best regards, JLC>Przemek JLC>_______________________________________________ JLC>Harbour mailing list JLC>Harbour@harbour-project.org JLC>http://lists.harbour-project.org/mailman/listinfo/harbour _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour