MS Access - X Y Cordinates of Control Top

[isladogs]

Doh! Why didn't I think of doing that before!


I've been so focused on getting the mouse move stuff working accurately I neglected more basic stuff!

Anyway its now perfect - screen flicker removed completely in form 4 & popup!

Will test in 64-bit as requested - I think I can guess what the issue is

[isladogs]

I've now tested this in 64-bit and needed to make one minor change to a variable declaration.
Version 7 attached.
It now works in both 32-bit & 64-bit and, following Ajax's good advice, both forms 4 and 5 are now flicker free (at least for me)

The attached file contains the Access app, the Images folder & a Word doc giving an outline of what its meant to do
Please let me know how you get on with this version.

Later I'm going to go back to the forms 1-3 that I developed for another forum thread a few months ago.
I intend to add form setting options to:

• change border style
• Turn record selectors on/off
• Set scrollbars on/off etc

I may also add option of using mouse move code to those forms as well - currently double click events

Eventually I will publish this as another example database on my website

[orange]

Good stuff Colin. Thanks for keeping the forum up to date.

[isladogs]

Hi Orange
It was quite fun once I got the hang of the mouse move controlling listbox 'selection'
Just about to send you a PM

[ironfelix717]

Collin,

Good work. The only part i'm really interested in is how to retrieve the listbox Top Y coordinate dynamically, which it appears you have done by testing your file. Very cool. I will dissect the code to understand what the variables are and return back so it is clear to any readers of the post.


Regards

[isladogs]

No need for you to do that.
I intend to give a more detailed explanation when I put it on my website.
When I do so, I will return and add a link from this thread.

[ironfelix717]

Colin,

Cool. Looking forward to that! I will await your website article.

Admins and Mods: Please keep post open until we all agree that topic's solution has been clearly stated and solved! Making progress!

[isladogs]

Website article will hopefully be done in the next couple of days depending on other commitments

[ironfelix717]

Colin,

Update: I played with the code and although I didn't take the time to dissect each part of it, i understand the basics of how it works.

The converttoTwipsYFromPoint function calculates a height (twips) from a given font point size. I read the code comments from Stephen Lebans and yourself. Can you explain why the use of APIs is required to calculate the text height? The more APIs i can stay clear from the better.

Lastly, I found an issue... Whether or not you have noticed this... It appears at some point down the height of the listbox, the selection versus mouse location generates error. The error is enough to be extremely noticeable. Playing with your sample (i'm talking form 5 here), Right at item 7 the error begins and by the time the cursor reaches item 8, the error is very great... Adapting the code to my application also shows this behavior, however i am using 9pt font in my listbox and the error becomes drastic by item #3.

Any idea why this is? Any relation to the function above? I will continue to fiddle with this. Awesome work.

Regards

[isladogs]

The calculation is normally close but I agree, not absolutely perfect, especially at vary small or very large point sizes.
Its also more noticeable in some fonts than others.
In my view its close enough but you are welcome to tweak it further if you wish.

I will also have another look at it myself to see if I can improve it any more (see below)
The listbox row height (LBRH) is a simplified version of the calculation done by Stephen Lebans.
APIs should be used wherever they make code simpler, faster or more reliable
All code I've ever seen for this type of work uses APIs
A good example is code to automatically resize forms depending on screen size, shape and resolution
If you think you can do this without APIs, that would be great ... but if Stephen needed them I think the rest of us will need them as well

Attached is a modified version of a utility by Stephen that I used to check the height of a listbox depending on the number of records and font size.
It explains why I made comments about the first row always being 45 twips (3 px) taller no matter what the font size
BTW - you need to change to design view to modify the font size/name - I didn't bother to build in code to do so in form view as it was just used for testing.

Have a look at his more complex code and possibly use that instead
The reason why the discrepancies occur is I think due to conversion issues between points, pixels and twips.
As the supplied Word doc states:
The position of objects in the Access window is determined in twips (1440 twips = 1 inch ; 567 twips = 1 cm) where the x-y coordinates of the top left of the application window are 0, 0
However, the position of the mouse cursor is measured in pixels with reference to the overall screen:1 pixel = 15 twips so 96px = 1440 twips = 1 inch
Font size is measured in points where 72 point font = 1 inch = 96px so 12pt = 16px = 240 twips = 1/6 inch
See https://websemantics.uk/tools/conver...m-rem-percent/

So far so good
The problems occur when a font size is not an exact fraction of 72. For example 11pt = 15px (approx) but actually 14.6667 px
However you can't have a part pixel so it has to be rounded up to 15px

When I first tested this I created a simple routine to see the results of the converttoTwipsYFromPoint function

Sub TestTwipsPointsConversion()   Dim I As Long, N As Long
   For I = 1 To 24
       Debug.Print "Point size = " & I & " ; Twips = " & converttoTwipsYFromPoint(I)
   Next
End Sub

Here are the results with apparent discrepancies highlighted:

As you can see each point adds 15 twips(1 px) but every 3rd point adds 30 twips (2px)
The explanation is of course that you can't have a part pixel so each value is rounded to the nearest whole pixel
If I do alter my code, that's one thing I will look into further. Possibly a Mod 3 adjustment ...but you still can't have part pixels!

[ironfelix717]

Colin,

Thanks for the explanation and arithmetic behind the conversion function... But my main point wasn't addressed... There is error occurring in both your sample and my application with this code (appears to be regardless of fnt size). The mouse position relative to the selected item becomes greatly different towards the end of the list. See attached. Any idea why this is occurring? --the conversion has error?

[isladogs]

I certainly did address the point in my answer.
I knew it occurred but stated that I felt it was close enough.
In fact I gave a very detailed account of why I believe the conversion isn't exact.
As I said, I used a simplified version of the lebans approach.
Perhaps his conversion would be closer but I doubt its possible to make the highlight and cursor align absolutely perfectly in all situations.
I gave the reasons why there has to be some approximation.

As already stated, I was intending to review this again when I have the time.
If you think the discrepancy isn't acceptable, feel free to try and improve it yourself.

[CJ_London]

as mentioned many posts ago by myself and Colin, using a subform is so much easier - if only because row heights are full pixels so you don't get this issue. Other factors include much closer control of knowing where the cursor is relative to the top and bottom of the detail section (or control if full height, or a mixture of the two, you can control the row height (use a multiple of twips per pixel) and the fact you are not limited to a black backcolour to highlight the mouseover row and can use many other highlighting methods and (although not relevant to you, can be used on continuous forms). But you dismissed this out of hand and later said 'if I thought there was another solution....'

Be that as it may, suggest you play around with font sizes in your listbox until you find one that will generate a row height that is an exact number of pixels. Colin has spent an awful lot of time trying to help you and provide a large number of examples - I don't think you have done the same - so what works for Colin may not work for you if you are not using it in the same way

One final thing about listboxes - I haven't looked at the code in any detail, but have you considered what happens if the listbox has more rows than can be displayed?

[isladogs]

Thanks for those comments Ajax which I fully agree with
Surprisingly perhaps the code does work if there are more records in the listbox than fit the available space

FWIW I did make a mistake in the code and correcting it does significantly reduce though not completely eliminate the discrepancy

I wrote that the code should add 3pt to the font size but in testing I changed it to +2
So alter it as shown in BOLD RED text in form 4

Private Function GetListboxRowHeight()

   ......
    
    'My observations
    'Add 3pt to font point size and use function converttoTwipsYFromPoint(point size)
    'Then add +15 twips for each row (1px) ONLY IF font size is odd value
    'For row 1 - add a further 45 twips (3px)
    
    .......

   'get  listbox row height in twips
    'Typically a listbox row is the height of capital A with +3pt eg. 11pt font =>14
   
   'This gives approx correct answer - works well at 11/12pt - slightly less so at more extreme values
    LBFS = Me.lstContacts.FontSize + 3 
    LBRH = converttoTwipsYFromPoint(LBFS)
    
End Function

Do EXACTLY the same changes in Form 5

Another part of the issue is that whilst its logical to assume the cursor arrowhead is where the cursor actually is, that may not actually be true
I experimented changing the cursor arrow to an I-beam or <--> shape and the issue was almost entirely resolved
However I can't get this cursor shape to work consistently reliably at the moment and, to some extent, flickering returns.
So I've abandoned that idea for now

Finally another issue unrelated to my code. There is a slight latency between moving the mouse & that change showing on the screen
So there is brief gap between the actual cursor position calculated by Windows & that shown on the screen.
You'll see what I mean of you test when the CPU is under heavy load and struggling a bit for any reason.
There is nothing I can do about that other than buy myself a new PC

[ironfelix717]

Genetlmen,

I return after some time playing with the code.

The first thing I did was removed the API conversion function, as its just an unnecessary risk (and code) and replaced it with the following (which only supports select fonts of my choice):

Public Function PT2Twips(pointsize As Integer) As Long
Dim pt      As Integer
Dim tw      As Long


pt = pointsize


If pt <> 8 _
And pt <> 10 _
And pt <> 11 _
And pt <> 13 Then
    MsgBox "Font size not supported for mouse-over selection"
End If


Select Case pt
    Case 8: tw = 150 + 95
    Case 10: tw = 195 + 72
    Case 11: tw = 210 + 84
    Case 13: tw = 255 + 90
End Select


PT2Twips = tw
End Function

You'll see above, my practically arbitrary "adjustment" factors for which I found to be "adequate" for that font size. Mathematically they make no sense, but I could care less.

I don't fully agree yet that the error is a result of rounding. "Perfect" factors of 72 still exhibit the error.

It should be known when I achieved this functionality some week or two ago, I also experienced error. But thought I solved it with some bugging around in the code, only to find it remained after looking at your solution.

This is going to just have to be something we accept, I suppose.

Ajax:
In regards to a subform solution, be my guest. If you can satisfy the requirements I listed ten or more posts ago, then sure. But I have doubts. A listbox is the premier tool for listing items. How will you add and remove items? What controls will represent the rows? i think you would find its cumbersome and not well adaptable/expandable. - Especially if you have to query the row data.

Your code has allowed my original listbox selection solution to be placed anywhere on the screen without manual locating, which I still do not understand what the significant difference is. Perhaps you can give a rough explanation how this requires no "locating" factor?


Regards,