On Thu, 22 Apr 2010, Pritpal Bedi wrote: Hi,
> I am helpless that I cannot create a self-reduced sample. > What I did, just created the standard methods instead of > calling INLINE and everything went fine. > > I am not sure if changing the method calling convension > has anything to do with OLE object. It has nothing to anything. It works just like standard methods though it's a less efficient due to one additional function stack frame which is created during execution of inline methods so the memory alignment is a little bit different and it can interact with some buggy code which access non initialized memory or use wrong pointers or even keep some indirect references to function methods in C structures. > For now my problem is over and in future I will always > take care that INLINE instance variable access/assign > should never peep into my programs. Just to remmeber, > I re-mention that the same code worked absolutely OK > before 15 Mar and this code has nothing to do with OLE > changes in GTWVG. I am using my local implementaion > of ActiveX code because of one nasty active-x ( VisiLabel ) > which is not standradized OLE. The fact that in the past some code was executed without GPF does not mean that it was ever correct. In this particular case GTWVG ActiveX code is still not production ready. As I can some things have been fixed by coping some parts of contrib/hbwin/axcore.c to contrib/gtwvg/wvgsink.c but still some other are not resolved, i.e. WVG_AXSETUPCONNECTIONPOINT() allocates memory for OLE objects and this memory is never released and the code which should do that is commented, probably due to GPFs. I do not see any code which increase reference counter before returning the pointer to PRG code so such GPF is expected behavior inside WVG_AXSHUTDOWNCONNECTIONPOINT(). And as far as I know this code existed here for very long time. Of course it's probably not the reason of your problems but it shows that this code is not such perfect as you suggested. > There is one pending issue of similar nature which Shum posted > some days back. If will be kind if you look into that issue. > It pertains to object instance access/assign from within > exe to an object created in a Harbour compiled .dll. > Shum, can you show that code again ? I've seen this message and I haven't found anything what suggested any problems in core code but maybe you see sth what I'm missing so please be so kind and tell me what I should check or better please create self contain as small as possible example which we can compile and test ourselves. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
