'N' appears when spacebar is pressed

[hua]

Guys, any of you had this happen to you? When you press spacebar, instead of a blank space your get displays 'N' instead. Running fwh\samples\testget.prg and testget6.prg doesn't give me that problem though.




Any idea on how to go about troubleshooting this is also appreciated.

Using FWH11.6+Harbour+BCC5.82

[hua]

The next step I did to try to determine the source of the problem:
i. Linked-in tget.prg from fwh\source and insert OutputDebugString() at line 1135.
ii. Compile with harbour binary downloaded from http://code.google.com/p/harbour-and-xh ... p&can=2&q=

Turns out the nKey value here (::KeyChar()) is already 78 not 32. What's next to check?

[Antonio Linares]

Hua,

Could you provide a small example to reproduce it here ? thanks

[hua]

Strange, compiling using xHarbour makes this specific problem goes away. Unfortunately it also means the comeback of some bugs that have been resolved so can't stick to it.

[Antonio Linares]

Hua,

have you checked that you are not linking a modified Class TGet ?

Could you provide a small example ? thanks

[hua]

Attempts to create a reduced-self contain example so far failed Antonio. The tget.prg was taken directly from fwh\source. I'll give a try again.

[Randal]

Hua:

Strange, compiling using xHarbour makes this specific problem goes away. Unfortunately it also means the comeback of some bugs that have been resolved so can't stick to it.

What bugs are you referring to?

Randal

[hua]

What bugs are you referring to?

The xHarbour bug is some commands that are supposed to observe SET DEFAULT TO didn't. There was also another bug I reported regarding a zip-related function. All were submitted to the bug reporter. After monitoring them for a while and seeing that they weren't resolved I just forgotten about them

[Roberto Parisi]

I had the same problem occasionally (not only N but also other chars). It seems a memory problem because I solved it calling some hb_gcall() in the code.
In xHarbour I never had this behavior.

Regards,
Roberto Parisi

[hua]

I also don't have this problem in xHarbour but compiling my module in Harbour solved some other problems for me. To be fair, my xHarbour version is fairly outdated.

So far I manage to recreate the problem when dynamically loading keylib32.dll (a dll from SoftwareKey). Still chopping my test code further so could get a reduced self-contained sample.

Thanks for the tip about hb_gcall().

Anyone has a snippet on how to use the native hb_libload() in Harbour? Seems it's expecting 2 parameters instead of 1

Code: Select all

hb_libLoad( PHB_ITEM pLibName, PHB_ITEM pArgs )

. I was wondering whether it would help due to this note in Harbour's changelog

Code: Select all

2008-10-13 20:21 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/source/rdd/wacore.c
    ; updated comments about Xbase++ behavior in dbRelease()

  * harbour/include/hbvm.h
  * harbour/source/vm/hvm.c
  * harbour/source/vm/dynlibhb.c
  * harbour/source/vm/runner.c
    ! added MT protection for HB_LIBLOAD()/HB_LIBFREE() and
      HB_HRBLOAD()/HB_HRBUNLOAD(). Please remember that you should
      not use any external LoadLibrary() functions because they are
      not protected for clean PCODE modules loading/unloading even
      in ST mode. Using them can cause HVM internal structure corruption.
      If we have such functions in contrib then they should be redirected
      to our HVM ones.
      There is still one problem in MT mode which has to be resolved yet.
      When dynamic library containing PCODE using static variables
      is loaded 1-st time then it will force resizing of internal array
      with static variables. If in exactly the same moment some other
      thread operates on static variable then it may cause corruption.
      To resolve this problem we will have to divide continuous memory
      block common for all modules where we store all static variables
      into separated blocks bound with each PCODE module (symbol table).