Problem with the format property of a combo box.

[AHeyne]

here is another demo, the code provided by Mr.DougSteel.

That's also a nice solution that works. But I find the boilerplate code for this type of solution too large.
Sure, I could encapsulate it in a class, but I would still have additional controls. I still tend to favor the solution mentioned above.

 

[arnelgp]

if you have already a solution just ignore the sample db.
the demo db is for others, who will find your post and will
find it useful for them.

 

[sonic8]

In classic Windows edit controls, for example, each control has its own window handle.
Access controls do not seem to have this, or at least Access does not disclose it.

This is the essential difference in the context of my suggested solution.
And most Access controls are only real windows with their own window handle while having the focus. Once they loose the focus they become just "pixels on the screen" without existing the Windows window hierarchy.

 

[AHeyne]

This is the essential difference in the context of my suggested solution.

I'm not sure if you're trying to tell me that your suggestion should work... ...or not.

But I tried something yesterday (quickly, with ChatGPT's help) and didn't get any results either.
I've attached this non-functioning database (I've not yet tried to invest more time to check if there's maybe any bug in the api usage, maybe later).

 

[sonic8]

I'm not sure if you're trying to tell me that your suggestion should work... ...or not.

Neither. I just wanted to elaborate on the difference of standard Windows controls and Access controls with regards to my suggestion.

I expected the API approach to work at least while the control has the focus. Sadly, even this is not the case. I also quickly tried it now.
My approach is very similar to your ChatGPT based approach. Your code to get the control's Windows handle could be reduced to just:

ctrl.SetFocus
hWndFocus = GetFocus()

It doesn't make any difference though.

 

[AHeyne]

Thanks for the info @sonic8 . So I won't invest more time in it.

 

[cheekybuddha]

I haven't read this whole thread, so forgive me if this is irrelevant or already covered.

If you need the hWnd of an Access control there is a method here on The Access Web:

API: hWnd of Controls

 

[AHeyne]

@cheekybuddha : Thats already covered in my example here.

 

[isladogs]

Access controls (text boxes, combo boxes, etc.) are not classic Windows edit control windows, but rather Access-specific containers.
I can't describe it any other way, as I can't find any reference for this statement.
However, that's how I remember it from the past.
In classic Windows edit controls, for example, each control has its own window handle.
Access controls do not seem to have this, or at least Access does not disclose it.

There is almost no documentation about this so I wrote an article on the topic a couple of months ago:

Windowed & Non-Windowed Controls in Access

This article explain the differences between the two types of control available in Access, the properties of each and how this affects how each type can be used.

www.isladogs.co.uk

As you mentioned most Access controls are non-windowed and only get a windows handle when they have focus.
The exceptions are windowed controls (listboxes, subforms, modern charts, legacy/modern browser controls, most ActiveX controls).
Those do have their own windows handle though these can be rather inaccessible)

I do have working code to get the handle of all form controls which I can pass on if it would be useful.
The code isn't mine - it was written by John Mallinson who is the author of the excellent VBE_Extras add-in

 

[AHeyne]

Thanks for the offer, Colin, but as Phil already said, it doesn't work in his test with the API either. However, retrieving the control window handle seemed to be the least of the problems.

I trust his expertise and won't dig any deeper into this.