Regarding Accelerators

[jscholes]

Just to add, I looked through the PureBasic manual for any mention of this. To illustrate what I mean, this concept is referenced in the documentation for creating menus and adding items:

The text to display in the title item. On Windows you can use the special '&' character to underline a specific letter:

"&File" will actually display: File

In other words, if you create a menu with the title "&File", you'll be able to open it with Alt+F. If you create one with a title of "Co&nnection", the hotkey Alt+N will make the menu drop down. You see what I mean about this being core functionality? In all the dialogs provided by the OS, e.g. FileRequester, this functionality works. It works in message boxes created by MessageRequester. It works with menus. But it doesn't work with control labels. And it should.

[PB]

> unless I can get access to it using PB,
> the language won't be viable for me

So, rather than just use a little loop to set up the shortcuts,
you'd look for an entire other language? Why make it so hard
on yourself? It's not that big of a deal. Chuck the loop in and
you're done. But yeah, it's your choice.

> You see what I mean about this being core functionality?

I've used plenty of other languages that didn't have "core"
functionality, too. Visual Basic was one such example: you'd
have to buy third-party controls to add to your form to do
certain things that it lacked -- even basic winsock work!

It's not a problem unique to PureBasic by any stretch.

[skywalk]

In the past, I've created GUIs using wxWidgets (wxPython), C#/WinForms, AutoHotkey and AutoIt. In all of those cases, creating a form with the labels stated above would exibhit the following behaviour in terms of keyboard access:

Why are you investigating Purebasic if your other languages provide what you need?
Unless you post a bug or feature request, I am at a loss to understand your approach here.

[jscholes]

PureBasic is NOT for Windows. It's for Windows, Linux, and Mac.

This is probably where your frustration lies. Anything that you expect to
work because of Win32 is not the case here. Each and every command
and gadget has to work the same way on all three platforms, or it simply
isn't supported. This doesn't make it a PureBasic bug, though. It's a design
decision/limitation/whatever.

Have you heard of wxWidgets? It is a native GUI toolkit used in tons of applications across multiple window managers and UI systems on multiple platforms. Everything works the same across all of them, and all of them work as expected. That's the point of native GUI functionality. Just because everything has to look the same to the developer who is using the toolkit or, in this case, the language, behind the scenes the Win32 support and, say, the OS X Coco support are as different as night and day.

Cross-platform does not mean sacrifices have to be made, and even if it did, as you'll see from my post before this one, Windows-specific functionality very closely related to this exists in the Windows backend for PureBasic's GUI library. This is an oversight or error, not a design choice. It would be good to have someone as knowledgeable about PB as yourself on board with tracking down this problem, but you have to understand that it is one in the first place.

[jscholes]

Why are you investigating Purebasic if your other languages provide what you need?

Because they don't provide what I need, i.e. all of PureBasic's other features which I have not found fault with and actually quite like. For this project, the language is perfect but for this one problem. I would happily raise an enhancement request or bug ticket if I understood where the problem was coming from.

[jscholes]

It seems that I've gotten off on the wrong foot with this community. Honestly, it is not my intention to raise a problem where there isn't one or to make life difficult for myself. Which is why I would love it if this problem were solved, because believe me, if you worked with assistive technology, technology used by the visually impaired and people with other disabilities, you would understand why making life difficult for myself is the last thing I want to do. If the Win32 support didn't have this bug, I could make my app keyboard accessible by adding a few ampersand signs. That is how, according to MSDN, every Windows programming book on the planet, and heck, even some members of this forum, it should work. I will dig around and find posts where this approach is referenced.

[PB]

> I could make my app keyboard accessible by adding a few ampersand signs

I showed you a real-world working solution to this exact request.

Instead of embracing it and moving on with your app, you're arguing that
it's a terrible solution and rejecting it on principle, which is just silly.
You can either waste time researching and trying to "prove" why it's so
bad and wrong, or quickly add the snippet and get on with coding.

[jscholes]

> Have you heard of wxWidgets?

Yep, and PureBasic doesn't use it, so it's a moot point.

Anyway, post your problem in the "Feature Requests" section,
and see if the team agrees that it should work as you say.

> I could make my app keyboard accessible by adding a few ampersand signs

I showed you a real-world working solution to this exact request.

What's so bad about using such a solution in the short term? It's
just a simple matter of pasting a 10-line code snippet into your
source. I really don't get why it's so bad in your eyes. It's like
you're rejecting it on principle, which is just silly. Seriously.

> It seems that I've gotten off on the wrong foot with this community

No, you're just being silly. Rejecting a tiny working solution just because
the language "should do it by default" is just dumb. Sorry, but it is.

I reject your solution, to put it bluntly, because Microsoft invented a better one twenty years ago, as I already stated. Research MSAA, UIA, and other accessibility APIs and how they are used by screen readers to make computers accessible to the blind. And then tell me that ten lines of code will do it justice. It won't work even remotely the same, and if I took the time to go into why it wouldn't, I would end up writing a book on the subject.

But technically speaking, this is, at its core, an incorrectly implemented part of PureBasic's native GUI support on Windows. I speak from technical experience, and from the perspective of someone who uses this technology every day. I am using a screen reader to read the web page on which I am writing this reply to you, because I'm almost completely blind. I rely on software venders getting accessibility just right because one screw-up, however small, can make an app unusable. So until you have any experience with any of that, you are not at liberty to say that I am dumb, silly or any other adjectives you wish to throw my way. Your solution is good. I commend your efforts. You have used the language constructs provided to you and made something which patches part of the problem. But it doesn't even begin to cover it. I would rather use Win32 natively than monkeypatch my event loop to add half-baked accelerator support all over the place.

[PB]

> you are not at liberty to say that I am dumb, silly or any other adjectives

I toned down my post because it was a bit rude, I must admit. Sorry mate!

But I still think you're wasting time trying to make it work the way you want.
Post your problem in the "Feature Requests" section and see what the team
has to say. They may agree with you and shock us all by implementing it.

> I would rather use Win32 natively

You know you can do that with PureBasic, right? Almost every Win32 API
call/function can be called natively directly in your source. So the solution
to your problem is already there, if you know the calls/functions already.

[jscholes]

Also, just to briefly explain why I brought up wxWidgets:

I know PureBasic doesn't use it, of course. But it is a cross-platform GUI framework, using native controls on all platforms. Just like PureBasic's gadget system which attempts to do the same. They wrap the same functionality, the only difference is that in this one case, they do it better. Because accelerators work. If they work in that system, they can work in this one. wxWidgets never made a design choice to make them work, they simply... do. Because they're a part of Windows. If I told you to implement your own file open or save dialogs, you'd look at me as if I had two heads. This is exactly the same, only on a smaller scale which effects fewer users.

[skywalk]

It won't work even remotely the same, and if I took the time to go into why it wouldn't, I would end up writing a book on the subject.

You are nearly there

I would rather use Win32 natively than monkeypatch my event loop to add half-baked accelerator support all over the place.

You can call any win32 api directly and not use the wrapped PB gadgets. I was expecting you to do this as presentation of a bug in PB's gadget library. If you cannot, I will move on.

[PB]

> You can call any win32 api directly and not use the wrapped PB gadgets

For a practical example of this, see this thread:

http://www.purebasic.fr/english/viewtopic.php?p=456540

You'll see how NetMaestro totally changed my PureBasic gadget code to
the native Win32 API version, all from within PureBasic. Hope it helps.

[jscholes]

> I would rather use Win32 natively

You know you can do that with PureBasic, right? Almost every Win32 API
call/function can be called natively directly in your source. So the solution
to your problem is already there, if you know the calls/functions already.

Such a solution would require implementing my own event loop to process window messages. It wouldn't be a simple matter of just creating my controls with the API directly. I know it's doable, but... then I'm not using PureBasic anymore. I'm using Basic syntax and C-like coding style. The product loses most of its value.

[PB]

Oh well, we tried to help. Sorry that we couldn't.

[jscholes]

Oh well, we tried to help. Sorry that we couldn't.

Your link to the Windows API code example does help, and I will implement a version of my sample program using native API calls. Hey, if it helps track down the bug, it has to be worth a try.