Stephen Lebans clsToolTip 1.4 fails on new server / Access (1 Viewer)

Rx_

Nothing In Moderation
Local time
Today, 03:20
Joined
Oct 22, 2009
Messages
2,803
To allow for enhanced custom Tooltips for Access Form controls

This is a nice class object for creating a custom tooltip with VBA for use in Access.
Alas, Stephen Lebans web page has since retired.

The code worked on a Citrix server with a Windows Server 2003 OS on Access 2007
Testing it with the lastest Windows Server and Access 2010 - it fails.

My guess is that Windows Server 2008 (I am checkin on the exact version) may not support native user32 libraries?
Any ideas? The Stephen Leban Tool tip is just awesom for users.
Example of the Declare Statements:
Code:
Private Declare Function apiGetScrollInfo _
Lib "user32" Alias "GetScrollInfo" (ByVal hWnd As Long, _
ByVal n As Long, lpScrollInfo As SCROLLINFO) As Long
Private Declare Function GetWindowRect Lib "user32" _
(ByVal hWnd As Long, lpRect As RECT) As Long
Private Declare Function ClientToScreen Lib "user32" _
(ByVal hWnd As Long, lpPoint As POINTAPI) As Long
Private Declare Function ScreenToClient Lib "user32" _
(ByVal hWnd As Long, lpPoint As POINTAPI) As Long
Private Declare Function DeleteDC Lib "gdi32" (ByVal hDC As Long) As Long
 

Rx_

Nothing In Moderation
Local time
Today, 03:20
Joined
Oct 22, 2009
Messages
2,803
The IT group has informed me that the new server is: Windows Server 2008 R2 Office 2010 32 Bit

The exact same code is still working fine on the Windows Server 2003 using Office 2007.

Thank you so much for your response. I really appreciate any and all ideas. So far, every other feature in Access appears to work. Of course the call to the Windows API was a huge exception to the code. But, the custom tool tip feature is very popular.

Found this Microsoft article related to the PtrSafe
http://msdn.microsoft.com/en-us/library/ee691831.aspx
It gives the appearance of only being needed for Office 64 Bit
Do you suspect that the Windows 2008 R2 requires the PtrSafe regardless of the MS Office 2010 version?
 
Last edited:

boblarson

Smeghead
Local time
Today, 02:20
Joined
Jan 12, 2001
Messages
32,059
I'm going to see if anyone else knows as I would not see that it should fail if it is 32 bit Office and not 64 bit.
 

Rx_

Nothing In Moderation
Local time
Today, 03:20
Joined
Oct 22, 2009
Messages
2,803
Thank you very much.
Some sites only say it is required for Office 64 bit. This site might suggest that the Windows version makes a difference too.


64-bit support, primarily for API calls. This is both used to make your code work with your OS/Office version as well as others' (i.e. someone on Office 2003/WinXP)
  • If you are on a 64-bit version of Windows, but are on a 32-bit version of Office, you can declare API calls like below.
#If Win64 Then Declare PtrSafe Function GetTickCount64 Lib "kernel32"() As LongLong#Else Declare PtrSafe Function GetTickCount Lib "kernel32" () As Long#End IfIf you are on a 64-bit version of Windows, and are on a 64-bit version of Office, you can declare API calls like: .

#If VBA7 Then Declare PtrSafe Function FindWindow Lib "user32" Alias "FindWindowA" ( _ ByVal lpClassName As String, _ ByVal lpWindowName As String) As LongPtr #Else Declare Function FindWindow Lib "user32" Alias "FindWindowA" (ByVal _ lpClassName As String, ByVal lpWindowName As String) As Long
#End If
 

Rx_

Nothing In Moderation
Local time
Today, 03:20
Joined
Oct 22, 2009
Messages
2,803
With 2 computers set up - Windows XP running Office 2007 (32 bit)
- Windows 7 Enterprise (32 bit) running Office 2010 (32 bit)
The Access application running from a trusted desktop location and with macros enabled fails on Windows 7 (32 bit) workstation with Office 2010 32bit
Works perfect anywhre from the XP workstation with Office 2007 32 bit

Code Modules References look OK.
Set my Compatibility Mode for MSACCESS.EXE on Windows 7 to XP. Same result.
Even opened access 2007 and saved as the access application in Access 2010.
Going to take this home to try on my own workstation. Thanks
 

Banana

split with a cherry atop.
Local time
Today, 02:20
Joined
Sep 1, 2005
Messages
6,318
Having worked with both 32-bit Access on 64-bit and 64-bit Access on 64-bit OS, I can assure that user32 lib is still available and should work. On a 32-bit Access (irrespective of whether OS is 32/64 bit) you can use the older VB6 declaration format and 2010 will still recongize it. However, PtrSafe is mandatory on 64-bit Access. I would say it's a matter of good practice to eventually port your API declarationsinto VBA7 format.

But that's not addressing the actual problem.

I can say I've used 2 of the API listed just fine in both scenario (with either declaration formats). The other 3, GetScrollInfo, ScreeenToClient, and ClientToScreen are not familiar to me.

My inclination would be to check Err.LastDllError at each point where Lebans' code invoke an APi and see if they give more information. I know I've run into one case where a API function (can't remember what it was) was deprecated and is no longer supported on newer OS and therefore we had to use a different API. That may possibly be what is going on here. One way to be sure is to visit MSDN reference for those APIs and see what the documetnation has to say about the functions.

Hope that helps you get started on troubleshooting.
 

Rx_

Nothing In Moderation
Local time
Today, 03:20
Joined
Oct 22, 2009
Messages
2,803
Err.LastDllError - thanks, in all my searching this never came up, can't wait to try it.
Took my code home and it ran exactly the same (worked properly) on one of my XP SP 2 with Access 2007 workstations.
On my Windows 7 64 bit workstation with Access 2010 - it actually warned me that my DLL code needed to be updated with the "ptrsafe" prefix.
Back at the client site, setting Access 2010 exe compatibility mode to XP SP3 resulted in an error (have since error trapped for the sake of users).

Will look into your idea. Thank you very much!
 

Rx_

Nothing In Moderation
Local time
Today, 03:20
Joined
Oct 22, 2009
Messages
2,803
Sorry to take so long. The conversion to Access 2010 (from 2007) seems to have small, but real issues.
Had created code to verify Office 2010 was 32 bit on desktop development and the server. Someone else responded with these two function - thought it might help others later since this question keeps coming up.

My result is 7 for VBA Version.
And Platform Version is 1 Both PC / Server Windows version are 32 bit.
The Last DLLError = 87
Code:
Option Explicit
Option Compare Database
Public Enum OfficePlatformVersion
    Office64 = 2
    Office32 = 1
End Enum
Public Function DetectOfficeVbaVersion() As Integer
#If VBA10 Then
DetectOfficeVbaVersion = 10
#ElseIf VBA9 Then
DetectOfficeVbaVersion = 9
#ElseIf VBA8 Then
DetectOfficeVbaVersion = 8
#ElseIf VBA7 Then
DetectOfficeVbaVersion = 7
#ElseIf VBA6 Then
DetectOfficeVbaVersion = 6
#ElseIf VBA5 Then
DetectOfficeVbaVersion = 5
#ElseIf VBA4 Then
DetectOfficeVbaVersion = 4
#ElseIf VBA3 Then
DetectOfficeVbaVersion = 3
#ElseIf VBA2 Then
DetectOfficeVbaVersion = 2
#ElseIf VBA1 Then
DetectOfficeVbaVersion = 1
#Else
DetectOfficeVbaVersion = 0
#End If
End Function
Public Function DetectOfficePlatformVersion() As OfficePlatformVersion
#If Win64 Then
DetectOfficePlatformVersion = OfficePlatformVersion.Office64
#Else
DetectOfficePlatformVersion = OfficePlatformVersion.Office32
#End If
End Function
 

Users who are viewing this thread

Top Bottom