newlisp.dll with get-string Bug

HPW · Post by **HPW** » Mon Dec 08, 2003 7:23 am

In newlisp.exe:

> (import "newlisp.dll" "dllEvalStr")
dllEvalStr <11180BC>
> (get-string (dllEvalStr "(+ 3 4)"))
"7"
> (print(get-string (dllEvalStr "(append \"test\" \"2\")")))
"test2""\"test2\""
> (silent(print(get-string (dllEvalStr "(append \"test\" \"2\")"))))
"test2"

In newlisp.dll:

Code: Select all

(import "newlisp.dll" "dllEvalStr")
dllEvalStr <19880BC>
(get-string (dllEvalStr "(+ 3 4)"))
7"7"
(setq a(get-string (dllEvalStr "(+ 3 4)")))
7"7"
a
"7"
(print(get-string (dllEvalStr "(append \"test\" \"2\")")))
"test2""test2""\"test2\""
(silent(print(get-string (dllEvalStr "(append \"test\" \"2\")"))))
""

Of cource I do not want to embed a newlisp in newlisp.dll.
It is only a test for use of other DLL. (zlib,zip etc.)
I want to access compressed or zipped data direct from newlisp exe and/or dll.

Lutz · Post by **Lutz** » Mon Dec 08, 2003 2:24 pm

Actually its doing the expected:

The newLISP dll reroutes stdout output to the return value, normally in newLISP console (for return values) and stdout output have a different path in the program, this is why in newlisp-tk you don't see stdout at all, becuase it is thrown away. So when working with nested newlsip DLLs the lower process's string return is a stdout on the next higher level. The stdout on the higher level in return gets a return value and routed to stdout (the console on the highest llevel).

Importing other DLLs into newlisp.dll things seems to work fine and only give one return value back, i.e. I try the following in the NeoBook demo (example from the manual):

(import "user32.dll" "MessageBoxA")
(MessageBoxA 0 "This is the body" "Caption" 1)
=> 1 ; single return value

Lutz

HPW · Post by **HPW** » Mon Dec 08, 2003 3:35 pm

Thanks for clearing.
Was not aware about the details of this.
Will further inverstigate the use of other DLL's.

Lutz · Post by **Lutz** » Mon Dec 08, 2003 4:06 pm

Yes, finding out about other DLL's would be great. It still would be nice to compile a combined DLL/Exe (like i.e. MS Excel), but we (Steve an I) haven't got that right yet. I also don't want to switch to MS-tools but rather stay with the free Borland tools.

Lutz