Apache OpenOffice (AOO) Bugzilla – Issue 115716
basic: Using strings with external functions (e.g. Windows API) leads to memory trash being received
Last modified: 2011-01-24 09:45:45 UTC
We have used this kind of macros to save some settings for our company's OOo macros (see attachment) for about two years now and never had problems with it until I recently tested the macros with OOo 3.3 RC6. With that version, every now and then, cannot tell exactly when and why, basic came up with the error "Aktion nicht unterstützt. Ungültiger Prozeduraufruf" (translates to: 'Action not supported. Bad procedure-call' or something similar). But sometimes there was no error and the macros got executed. I was kind of confused until I checked the Windows registry and saw the keys which were created in there by the macros (see attachment 2 [details]). I am pretty clueless why this happens, but this is a major problem for us, since we are using the Windows API (especially the registry calls) alot and it would cost me alot of time to rewrite all macros to use ini-files or something. Executing the macro in attachment 1 [details] should be able to reproduce this error.
Created attachment 75090 [details] Test Macros
Created attachment 75091 [details] Screenshot of windows registry
for user help please see the forums: http://user.services.openoffice.org
closed
How is this closed? I just tried it in RC6, because I thought it was fixed in there or just an issue with RC5, but it is still the same. These calls worked just fine till the last RC. A bit more of an explanation would be really appreciated, instead of refering to the most general forum link there is. Sorry, but this is really frustrating, because it just kills every macro our company is using and I cannot see the problem myself.
@ jsc are there some changes in the API?
jsc -> ab: do you have an idea? I think we should take a look on it
->mla: what was the reason to close this?
This issue is reproducable for me in a freshly installed Windows 7 with OOo 3.3 RC6 by the way.
ab->sb: Basic-DLL-Interface related, please have a look
Hamburg-internal issue #162141# "Runtime does not handle strings in the right way" changed the marshaling of Basic data used in "external DLL" calls (changes to basic/source/runtime/dllmgr.cxx, lumped together with many other things in <http://hg.services.openoffice.org/OOO330/rev/bd4551ecc553>). The corresponding tests unfortunately only checked that strings passed back from such an "external" call were correct (the string used in GetLogicalDriveStrings from kernel32.dll to return a list of null-separated drive strings). What apparently broke, however, is (1) to pass strings into such "external" calls ("Software\OOo_TEST_KEY" in lpSubKey of RegCreateKeyA, "OOo_TEST_DATA" lpValueName of RegSetValueExA), and (2) to pass strings into such "external" calls via "Any" ("THIS IS A TEST" in lpData of RegSetValueExA). For (1), the problem is that the terminating null byte is missing from the marshaled string data. The following patch would fix that: ---8<--- --- a/basic/source/runtime/dllmgr.cxx Tue Nov 23 16:56:16 2010 +0100 +++ b/basic/source/runtime/dllmgr.cxx Fri Nov 26 11:30:51 2010 +0100 @@ -207,6 +207,7 @@ } std::vector< char > * blob = data.newBlob(); blob->insert(blob->begin(), str.getStr(), str.getStr() + str.getLength()); + blob->push_back(0); *buffer = address(*blob); data.unmarshalStrings.push_back(StringData(variable, *buffer, special)); return ERRCODE_NONE; ---8<---
The second problem (pass string via "Any") might be a problem of the given test code or a problem of the Basic runtime implementation. I filed new issue 115795 to address this.
fixed as <http://hg.services.openoffice.org/cws/sb137/rev/8b54b81957e6>
[CWS sb137 has been abandoned in favor of CWS sb135, fix for this issue has thus been pulled into cws/sb135]
@tbo: please verify
Verified in CWS sb135 with attached macro; The name of the entry is now ok in registry written.
could integration in 3.3.1 pls be considerd? Thanks!
integrated into master DEV300m98 - closing