Issue with cwMenuBar in RC6 Widgets Reacting to Right Alt Key

Hello everyone!

I'm encountering an issue with the cwMenuBar component from the RC6 widget library where it incorrectly responds to the right Alt key instead of just the left Alt/Menu key. This is causing focus to be stolen from VB6 textboxes when certain keys are pressed.

Steps to Reproduce:

Place a textbox on a form.
Attempt to type the backslash "" using the right Alt key combination (Right Alt + "").
Notice that as soon as the right Alt key is pressed, the cwMenuBar takes focus from the textbox.
I've tried setting the keycode to 0 in the event handler, but it didn't solve the issue.

Has anyone else faced this problem? If so, did you find a workaround or a fix?

Thanks in advance for your help!

Looking at the vbWidgets source quickly, I see that it "watches" Tab, Shift, Ctrl and Alt keypresses:

https://github.com/vbRichClient/vbWi...s#L69C3-L69C19

But it doesn't make any distinction between left/right Ctrl/Alt/Shift as far as I can see.

That said, I've tried pressing RightAlt+" and nothing happens in any other regular Win32/64 application that I try it in. Pressing Left Alt or Right Alt naked also always moves the focus to the menu, so I'm not sure whether this Right alt distinction you are using is a common Windows input combo to do a "backslash """ (which I assume you mean is the “ character? or is it something else)?

Anyway, posting a minimal sample project might be handy, I don't have any projects using the cwMenuBar on hand and I don't feel like setting one up, but I don't mind poking around an existing project a bit to see if I can find a workaround ;)

Here it is.
I was "out of file space", so I had to delete some of the files I used in posts first.

Edit:
I had never seen the source code of the menu bar, and I wasn't aware it is open sourced.

So I can just use the class and change that myself, right?

I am currently a bit baffled... but it is only the widgets that are open source, right?

I downloaded your zip archive and decided to look at your project. But the project did not start due to the missing file RC6Widgets.dll.

Quote:

---

Originally Posted by tmighty2

Here it is.
I was "out of file space", so I had to delete some of the files I used in posts first.

Edit:
I had never seen the source code of the menu bar, and I wasn't aware it is open sourced.

So I can just use the class and change that myself, right?

---

Unfortunately the open source widgets are the old RC5 widgets. Olaf has yet to publish the latest RC6 widget sources (not sure what his plans are in that regard), so I don't recommend using the current open source classes directly. They can be useful as a guide though as I suspect the RC6 widget code only has a few small improvements/fixes compared to the older code.

Quote:

---

Originally Posted by tmighty2

I am currently a bit baffled... but it is only the widgets that are open source, right?

---

Yes, correct.

PS: I tried your example and pressing Right-Alt does move the focus to the menu, but this is normal behaviour in all non-RC6/regular Win32 apps I tried too. Is Right+Alt mapped to something different on your machine? Perhaps IME or some kind of keyboard helper app?

Quote:

---

Originally Posted by HackerVlad

I downloaded your zip archive and decided to look at your project. But the project did not start due to the missing file RC6Widgets.dll.

---

You will need to get the latest RC6 and RC6Widget libraries from https://www.vbrichclient.com if you want to run the code tmighty2 provided.

This seems to be a problem - even after I downloaded these libraries, the project still doesn't work. Runtime error 429 on the code line: "Cairo.SetDPIAwareness".

In short, I have no desire to deal with this complex library, it is unclear how to make it work at all. One thing is for sure, pressing the Alt key and shifting the focus to the menu is normal behavior, not a bug.

Quote:

---

Originally Posted by HackerVlad

This seems to be a problem - even after I downloaded these libraries, the project still doesn't work. Runtime error 429 on the code line: "Cairo.SetDPIAwareness".

---

Sounds like you didn't register the required DLLs (there's a bat file including in the ZIP that will do it, or you can do it manually via regsvr32 from an elevated command line).

Thanks, maybe I'll try again. Do you think the Alt key behavior is normal?

Quote:

---

Originally Posted by HackerVlad

Thanks, maybe I'll try again. Do you think the Alt key behavior is normal?

---

I do think it's normal for most locales, but maybe not for far-east ones? A bit of searching shows that Right-Alt is one of the hotkey used to toggle IME, so maybe that's the problem here.

You can you reproduce the faulty vs. the correct behaviour by choosing German keyboard layout in Windows (7, 10 or 11).

Make a new VB6 project and add a VB6 menu bar and a textbox to observe the expected behaviour of a menu bar.

Using a VB6 menu bar, type something in the textbox, then press the left "Alt" key (left to your space bar) and see how the menu bar gets the focus.
Note that even though the menu bar item is now highlighted and can be operated using the cursor keys, the textbox does not lose the focus. You can even continue typing, and the menu bar will be un-highlighted again.
In contrast to the left alt key, press the right alt key now and watch how nothing happens in regards to the menu bar.

It's quite a smart / good behaviour which the cwMenuBar unfortunately does not follow.

I hope that Olaf fixes this as it leaves one unable to type "", for example to enter a web address. At least I have not found a way around that. If anbody knows how to fix this / work around it, I would appreciate it.

Thank you!

The cKeyWatcher that the cwMenuBar uses is fairly simplistic and doesn't do any differentiation between left/right for keys like Ctrl/Alt/Shift as far as I can tell. Olaf's comment in the cwMenubar source indicates that this was just a "quick and dirty" attempt to get implement shortcuts for the widget, so it's likely that this was just an early work in progress that won't have the full functionality of Windows' input methods. TBH, I imagine it would be exceedingly difficult to completely match Windows' behaviour while still keeping things open to eventual cross-platform use.

That said, I'm not sure what Olaf's plans are re: updating the GitHub repository to the latest RC6Widgets code. When/if that's done I (and others) would be a bit more interested in contributing patches, but I don't really want to do any work against the old vbWidgets code in case it wouldn't be applicable to the newer codebase. Olaf, if you are out there, perhaps you could let us know if you plan on updating the repo to RC6Widgets, or are you keeping that in-house or moving onto other things entirely?

That said, I see that there are VK_* codes for Left/Right version of the Shift/Ctrl/Alt keys:

Code:

---

VK_LSHIFT        0xA0        Left SHIFT key
VK_RSHIFT        0xA1        Right SHIFT key
VK_LCONTROL        0xA2        Left CONTROL key
VK_RCONTROL        0xA3        Right CONTROL key
VK_LMENU        0xA4        Left ALT key
VK_RMENU        0xA5        Right ALT key

---

So it *should* be possible to write a keyboard handler that would offer different functionality based on L/R keypresses.

Try to write him a private message: https://www.vbforums.com/member.php?186525-Schmidt
But I don't think he's been online for a long time.

PMs to Olaf typically do not work in my experience, he receives so many that the forum PM system has clogged up and won't allow any more.
Olaf was online just three days or so back and answered some questions. It is all a bit hit and miss though.

Quote:

---

Originally Posted by jpbro

That said, I see that there are VK_* codes for Left/Right version of the Shift/Ctrl/Alt keys:

Code:

---

VK_LSHIFT    0xA0    Left SHIFT key
VK_RSHIFT    0xA1    Right SHIFT key
VK_LCONTROL    0xA2    Left CONTROL key
VK_RCONTROL    0xA3    Right CONTROL key
VK_LMENU    0xA4    Left ALT key
VK_RMENU    0xA5    Right ALT key

---

So it *should* be possible to write a keyboard handler that would offer different functionality based on L/R keypresses.

---

Right, ...
...within cwMenuBar.cls (which has unchanged Sourcecode from the GIT-published RC5-version),
one would have to do a replace of the (string)value 18 (vbKeyMenu) with the Value 164 (VK_LMENU)...(in 3 places)

One can override existing RC6Widgets.dll COM-Classes with similarly named "Project-Private" ClassModules
(just in case, this is not known).

Below is a zip-download, where I have done just that (now reacting only the the left-Alt(Menu)-Key...
https://vbRichClient.com/Downloads/MenuBarDemo.zip

Olaf

Thank you very much, it works as expected.

Quote:

---

Originally Posted by Schmidt

Right, ...
...within cwMenuBar.cls (which has unchanged Sourcecode from the GIT-published RC5-version),
one would have to do a replace of the (string)value 18 (vbKeyMenu) with the Value 164 (VK_LMENU)...(in 3 places)

---

Thanks Olaf, it's what I would have tried myself but I didn't think it was worth messing about with the old RC5 Widgets code in case any changes conflicted with the newer RC6Widgets.

Quote:

---

Originally Posted by Schmidt

One can override existing RC6Widgets.dll COM-Classes with similarly named "Project-Private" ClassModules
(just in case, this is not known).

---

Right, but now there's one more custom modded cwMenuBar floating around that doesn't include any improvements/new features in the RC6 cwMenuBar. If the latest RC6Widget code was on GitHub, then a pull request could have been submitted.

Anyway, if you don't want the trouble of dealing with all kinds of frivolous pull requests then I understand why you don't want to publish it, but I just want to confirm whether you plan on pushing the latest code to GitHub ever? Or do you recommend everyone just fork their own RC5 Widgets classes and make personal mods as necessary (possibly posting them here for others to integrate in their own forks if they want similar features)?

Quote:

---

Originally Posted by jpbro

If the latest RC6Widget code was on GitHub, then a pull request could have been submitted...

---

FWIW - here's the latest source for the RC6Widgets in a Zip:
https://vbRichClient.com/Downloads/RC6Widgets.zip

And you're right - currently I have no time to maintain the GIT-Repo for the Widgets.

Olaf

Quote:

---

Originally Posted by Schmidt

FWIW - here's the latest source for the RC6Widgets in a Zip:
https://vbRichClient.com/Downloads/RC6Widgets.zip

---

Thank you! Quick question - would you be against me putting the code on GitHub and (attempting) to maintain it? My free time isn't much better than yours these days, but I think I could make the occasional improvement and review the occasional pull request. It would be unofficial of course, but I would do my best to keep with the "spirit" of the code...no big crazy changes, aiming for efficiency and minimal bloat, etc... Anyway, let me know if that's OK with you, and if not that's fine too.

Quote:

---

Originally Posted by Schmidt

And you're right - currently I have no time to maintain the GIT-Repo for the Widgets.

---

Well I hope you're doing well and busy with the good/fun/rewarding stuff, and not just a bunch of bullshit ;) All the best as always.

Quote:

---

Originally Posted by jpbro

Quick question - would you be against me putting the code on GitHub and (attempting) to maintain it?

---

No problem - go ahead...

Quote:

---

Originally Posted by jpbro

Well I hope you're doing well and busy with the good/fun/rewarding stuff, and not just a bunch of bullshit ;)
All the best as always.

---

Not too much bull-juggling currently (it was getting better lately)... but thank you... :)

Olaf

Quote:

---

Originally Posted by Schmidt

No problem - go ahead...

---

Thanks Olaf, will do :thumb:

Quote:

---

Originally Posted by Schmidt

Not too much bull-juggling currently (it was getting better lately)... but thank you... :)

---

Glad to hear it! :)

For anyone interested, the RC6Widgets repository is available here: https://github.com/jpbro/RC6Widgets

I'll add a readme as soon as time permits.

Thanks again Olaf!

Quote:

---

Originally Posted by jpbro

I'll add a readme as soon as time permits.

---

Basic README is now up.

Olaf - do you have a preferred license for the RC6Widgets code, or should I leave it license-less? There's always this one ;)

PS: No rush to respond.

Using anything but MIT (or a derivative like MIT-0) license is a sure way to discourage any outside contribution. Some people use this tendency when they don't want to be actually bothered by overenthusiastic contributors.

cheers,
</wqw>

Quote:

---

Originally Posted by wqweto

Using anything but MIT (or a derivative like MIT-0) license is a sure way to discourage any outside contribution. Some people use this tendency when they don't want to be actually bothered by overenthusiastic contributors.

---

Good point. Hilariously I just noticed that the forum censored my link, so it's a questionable choice for a license for more than one reason!

Quote:

---

Originally Posted by jpbro

For anyone interested, the RC6Widgets repository is available here: https://github.com/jpbro/RC6Widgets

---

RC6Widgets is a great widgets set, full of skill and wisdom, but RC6Widgets are used in a completely different way than MS-CommonControls, which greatly reduces the usability of RC6Widgets.

If Olaf is willing to open source the cWidgetBase/cWidgetForm/cWidgetForms/cWidgetRoot/cWidgets, then I'll try to re-write all of Krool's CommonControls with RC6.

Also, it would be a great solution to re-implement all RC6Widgets based on ColinE66's cwGrid.

I am experiencing a bug related to cMenuItem.Checked: When not clicked manually but when being checked by code, the state does not redraw.
I was thinking that I could fix this myself using the Github classes. I understood it so that the "c" type classes can be "overriden" by using the "cw" type classes.
I went ahead and used "cwMenuItem" instead of the RC6 cMenuItem class (which due to its closed source nature didn't allow me to fix it myself), but I am now stuck at a pretty basic problem:

Code:

---

    Private m_Root As cwMenuItem
    Private m_MenuExistingAsMenuItem As cwMenuItem
    (...)
    Set m_Root = Cairo.CreateMenuItemRoot("root", "root") 'works
   
    Set m_MenuExistingAsMenuItem = m_Root.AddSubItem("mnuFileOpen", "Open...") 'does not work because "cwMenuItem" does not have "AddSubItem"...

---

Have I missed something?
Thank you for your help.

Hmmmm... The cwMenuItem found in the URL mentioned (as well as the GitHub project) does not seem to be the version used in RC6 widgets as e. g. "AddSubmenuItem" is missing which can be found in the closed source cMenuItem as the object explorer shows:

Code:

---

Function AddSubItem(Key As String, Caption As String, [IconKey As String], [Enabled As Boolean = Wahr], [Checked], [BeforeIndexZeroBased]) As cMenuItem
    Mitglied von RC6.cMenuItem

---

Or have I misunderstood something?

Quote:

---

Originally Posted by Schmidt

FWIW - here's the latest source for the RC6Widgets in a Zip:
https://vbRichClient.com/Downloads/RC6Widgets.zip

And you're right - currently I have no time to maintain the GIT-Repo for the Widgets.

Olaf

---

Quote:

---

Originally Posted by tmighty2

I went ahead and used "cwMenuItem" instead of the RC6 cMenuItem class ...

Have I missed something?

---

Yes, ... there is no bug in this case -
since the "primary" Class (to adjust Menu-State-Values) is the "data-container"-class of type:
cMenuItem

The bound GUI-Class-Type is cwMenuItem, which only reflects the data-class-value(s) - and is only there to influence "visual representation of the data".

A method behind e.g. your Menu-Root-Class, which can hand out an existing Item is:
SubItemByPathKey

as for example:
Dim SomeSubMenu As cMenuItem
Set SomeSubMenu = m_Root.SubItemByPathKey("Extras>Item4")
SomeSubMenu.Checked = Not SomeSubMenu.Checked

same as above, but shorter:
With m_Root.SubItemByPathKey("Extras>Item4")
.Checked = Not .Checked
End Wit

Olaf

Thank you for your answer. However, the attached project shows my success in not making it show a check even though being checked by code.
The property does change, but the visual does not.

Using a cwMenuItem class was not something that I started with. It was just my last ressort of things to try out.

I started just like you, but I do experience that bug.
I hope that the attached project's setup makes sense to you.

Thank you for having a look.

Quote:

---

Originally Posted by tmighty2

The property does change, but the visual does not.

---

The property changes on an entirely free-standing (unbound) root-tree (of cMenuItems) -
and then of course without causing any "visual changes" in the cwMenuBar-instance -
(since the binding happened via a "instancewise decoupling" JSON-string).

If you derive the real (the bound) root-tree directly from your cwMenuBar,
you will have no problem:

Code:

---

Private Sub Command_Click()
  With m_MenuBar.DataSource.SubItemByPathKey("mnuExtras>pEditMode")
      .Checked = Not .Checked
  End With
 
  pDisplayCurrentCheckState
   
End Sub

---

HTH

Olaf

Thank you.

Do you remember that I once mentioned an "Out of memory" error in the VB6 IDE about 3 years ago and that VB6 would not compile my app anymore? That error haunted me so much that I ended up rewriting almost everything I had coded for around 25 years, because I couldn’t get rid of it. Whenever I made small changes in an attempt to see if that would make the error go away, more and more parts of the code had to be changed as well, until in the end it turned into a complete rewrite.

After 2 years of this rebuilding / reconstruct process, I finally managed to rebuild and compile my biggest app again. During the process, I removed all "As Variant" as I was afraid that using Variant means additional work for the compiler, and that was something that I wanted to rule out. For some time, the "Out of memory" error no longer appeared – it became less frequent during the rewrite and eventually disappeared, but without any clear indication of what exactly had fixed it. But yesterday it came back. This happened after I integrated cwToolbar into my app.
Since it was copy & paste from your demo project to my big project, some variable names of course had to be fixed.

But instead of jumping to the error where the wronly named variable is being used, VB6 gave me the "Out of memory error" in the IDE again, and I was unable to fix the errors in that VB6 session.
What I did was to comment out all code that the compiler suddenly didn't recognize anymore, such as "Right", "Chr", "LTrim", "Hex", "Date", "Time", etc.


After I did this, I was able to save my project again.

I have the impression that casting from "c" to "cw" classes might contribute to the problem – not because there’s anything wrong with these classes, but perhaps because casting any Variant means extra work for the compiler.

It reminded me of something you once wrote in another context: that twinBASIC was currently not able to compile the large RC6 code base, and I wondered if the sheer size of RC6 and perhaps related castings instead of explicit declarations, maybe that is related – and the cwToolbar case just made me think of it again.

Size of RC6 does not matter when you are compiling your project. You are not recompiling RC6 from sources. Your project uses only RC6's typelib which is not ginormous by any standards. Theorethically if you reference many large typelibs the IDE might exhaust its symtables but I've never seen it happen in real life.

The most brittle part in compilation process is persisting usercontrols on forms. Each usercontrol has to be created, it has to read its properties from the text .frm file and then it has to write its properties in binary form in the output binary. This means that during compilation (in the IDE or to final binary) some VB6 code in usercontrols is executed i.e. someone might format your harddrive at compile-time but this is not the problem you have, someone might leak resources (GDI, memory, etc) at compile-time -- this sounds more plausible cause for your OOM troubles.

I've been battling to reduce our usercontrols footprint at compile-time for a long time as their Read/WriteProperties events cascaded into creating dependant instances to load images, fonts, whatever utility functions they were using. What I finally implemented is to put helper DebugInstanceInit/Term calls in each and every Class_Initialize/Terminate of our classes and make sure at compile-time DebugInstanceInit to dump a warning in Immediate Window that an instance is dubiously instantiated by Read/WriteProperties events. This helped me trace calls in the persistence events which we then guarded with Ambient.UserMode checks like this

Code:

---

        If Ambient.UserMode Then
            Set pPic = LoadStdPicture(ucsPicProductIcon)
        Else
            Set pPic = LoadPicture()
        End If

---

i.e. work as intended at run-time but reduce functionality to bare minimum while compiling (and at design-time) so no helper classes are instantiated.

cheers,
</wqw>

I think I understood that after the second read. Ensuring that your code does not trigger the instantiation of objects that in turn instantiate others?

re:Tmighty2, I think you may need to expose your code here and ask someone clever to look at it. There may be something that you are doing that is very wrong... or you may simply be meeting the limits of some VB6 internal resource.

Have you tried importing and compiling it with TwinBasic? Often TB throws up errors at import/compile time that VB6 does not care/know about.

> I think I understood that after the second read. Ensuring that your code does not trigger the instantiation of objects that in turn instantiate others?

The most important takeaway is that code in ReadProperties and WriteProperties events of a usercontrol are *executed* during compilation. The IDE prepares a temporary environment (not everything is as normal) and the interpreter runs actual code during compilation of forms which host usercontrols.

This means you cannot have a VB6 compiler clone (hint: TB) without first having an interpreter which can run code in Read/WriteProperties if you have to be 100% VB6 compatible. As a consequence it is your own resposibility to not leak resources in these events or stunt the compiler and make your project uncompilable. Instantiating global objects is one way to leak memory esp. if there are circular references involved.

The global objects are tricky as you never deallocate these as there is usually no harm these leaking when process terminates. It is during compilation that not leaking global objects becomes important as temporary environment is setup and teared-down on multiple occasions so you might leak multiple copies of such global objects.

cheers,
</wqw>