Apache OpenOffice (AOO) Bugzilla – Issue 111526
vbNullString does not work well for dll call, such as FindWindowA("",vbNullString)
Last modified: 2017-05-20 11:27:32 UTC
vbNullString does not work well in dll call ,such as FindWindowA("",vbNullString). Following VBA code(Open the Windows calc app first): Private Declare Function FindWindow Lib "user32" Alias "FindWindowA" (ByVal lpClassName As String, ByVal lpWindowName As String) As Long Private Sub CommandButton1_Click() Dim hWnd As Long hWnd = FindWindow("SciCalc", vbNullString) MsgBox hWnd End Sub According to the definition of Windows API 'FindWindowA', the second parameter: lpszWindowName Points to a null-terminated string that specifies the window name (the window's title). If lpWindowName is NULL, all window names match. We input vbNullString as the second parameter, in Excel, I think it is regarded as NULL, so FindWindow(...) can find the window, but in OOo, it can't find the window.
Created attachment 69408 [details] Test document for this issue
Created attachment 69441 [details] Patch for this issue
According to the definition of Windows API 'FindWindowA': The second parameter: lpszWindowName Points to a null-terminated string that specifies the window name (the window's title). If lpWindowName is NULL, all window names match. In the test case, we want to find the window that the class name is "SciCalc" and match all window names: winwnd = FindWindow("SciCalc", vbNullString) In OOo, vbNullString is defined as a empty String, it's different with NULL. So it can find the correct window. I check if the parameter is vbNullString or not, if yes, in dllmgr.cxx, I put a NULL into the parameters stack, please see the changes in SbiDllMrg::CreateStack(...). Please see detail in patch.diff
well I have to say, hats off for the getting stuck into the compiler code etc. But... unfortunately I find it hard to believe that we need to go to such lengths ( e.g. such a large patch ) to solve this problem :-/ I think ( erm I hope ) there should be an easier solution. The real problem to address as I see it is that a) vbNullString is incorrectly represented as an empty string instead of a null string b) possibly openoffice basic can't distinguish between a null ( e.g. uninitialised string ) and an empty ( e.g assigned to "" ) string, don't know if indeed that is the case need to look at that [*] c) dllmgr.cxx additionally needs to be aware of the difference between a null and empty string and needs to pass NULL for a NULL string ( at least for that api but probably this is a general rule ) VBA most certainly does ( as we can see from the example ) distinguish between the null and empty strings. Of course to make things more interesting it seems ( I just played a little with it in excel ) a null string mostly behaves exactly like an empty string most of the time, e.g. if you compare a null and empty string in basic they evalate equal ;-)
unfortunately I am begining to think it might be necessary to go to the lengths that you went to as there seems there no easy way that empty / null strings can be disambiguated :-( I wonder though is the patch set up so that unitialised Strings are treaded as Null e.g. dim foo as string Wnd = FindWindow("SciCalc", foo ) should yield the same result as hWnd = FindWindow("SciCalc", vbNullString) Andreas though is the expert here on all things basic compiler related and I give over to his wisdom
STARTED
I'm adding this comment to all open issues with Issue Type == PATCH. We have 220 such issues, many of them quite old. I apologize for that. We need your help in prioritizing which patches should be integrated into our next release, Apache OpenOffice 4.0. If you have submitted a patch and think it is applicable for AOO 4.0, please respond with a comment to let us know. On the other hand, if the patch is no longer relevant, please let us know that as well. If you have any general questions or want to discuss this further, please send a note to our dev mailing list: dev@openoffice.apache.org Thanks! -Rob
Reset assigne to the default "issues@openoffice.apache.org".