The normal way to do this is to precede the shortcut character with an &, but this does not seem to work with Win32::GUI.

Does anyone know an alternative way to make this happen?

Code

# set up the standard menu bar dropdowns: ie File Next Options View Help ... my $DataMenu = new Win32::GUI::Menu( # pulldown heading, note the "&" ampersand, in this context it is used # to indicate which letter gets the shortcut letter underlined

Are you sure the & is supposed to underline the char? I've never used Win32::Gui, but as far as I know based on my limited use of Tk, it defines the shortcut char. It's been awhile since I used Tk, but I think it had an additional option that told it to underline the shortcut. Maybe the same is true with Win32::GUI.

I went ahead and installed Win32::GUI and tested a few of its demo scripts and none of them have the menu shortcut underlined.

No, Iím not sure. I took that from the post I found that showed me how to define a dropdown combo box. The post also defined the dropdowns for the menu bar and stated that the & set up and displayed the shortcut keys.

I donít need that for the application Iím working on, just wanted to know the answer.

Iím relatively new to Perl and Iím struggling with the conversion of over 50 years of assembler, Fortran, C, C++, and other languages to Perl syntax.

Being open source, the documentation is not the best Iíve ever worked with. It reminds me of Andrew Tanenbaumís famous quote, ďThe good thing about standards is that there are so many to choose fromĒ.

Being open source, the documentation is not the best Iíve ever worked with.

Come on, you might have seen better documentation, for sure, I can agree with that, but the Perl documentation is really far from being bad (at least as far as core Perl is concerned, there are some modules that could be better explained). Having said that, there is sometimes a tendency (for some functions) to explain all the edge cases so that the overview of the main role or use of the function might be lost out of sight. I also write quite regularly software documentation and I can very well understand how this happens, sometimes you get lost into the details and forget to state the obvious (or what seems obvious to you). Having admitted that it is not always the best you would wish (for example, the pack/unpack documentation sucks), I think that the Perl documentation is usually quite good. And, concerning pack/unpack documentation, there is also a good tutorial that really alleviates the shortcomings of the official function documentation.

You could probably say the same about the printf/sprintf documentation: if, like me, you don't have to use it too often and need to check the documentation when you need it, you might get irritated... There, the problem might be that C programmers know these so well that many people might think it is obvious. Except that, in my case (for example), I don't think that I have written a C program with more than 30 lines of code in the last 12 years. The reason being that Perl is so good that I no longer need C, except in very special, unusual and seldom cases.

The biggest problem with Perl documentation and forum help is that there are often variations on how to do things. For example, there are multiple modules that handle the creation of a GUI interface. If you merely ask a question on how to do something, you can easily get multiple answers, all of which are correct for the person answering the question, but they often depend on what modules that person is using.

Again, I state the Tanenbaum quote, ďThe good thing about standards is that there are so many to choose fromĒ. When the language and documentation are strictly enforced by a single enterprise, like Microsoft or Apple, then there is generally only one real answer, and in general the suggestions that are offered will at least compile and run.

If you merely ask a question [referring to Perl] on how to do something, you can easily get multiple answers, all of which are correct for the person answering the question, but they often depend on what modules that person is using.

The same is true when referring to Microsoft.

How about this question, which is a common question in Perl forums and has multiple answers.

How do you edit a line in a text file?

MS answer: You could use the MS edit.exe (or is it edit.com) text editor or Notepad or Wordpad or MS Word or batch script or powershell or VB or several other options.

Within each of those options with the possible exception of the first there are multiple ways to edit a line.

A lot of commonly asked perl questions that get multiple solutions also have multiple non perl solutions both scripted and non scripted. If multiple solutions are not wanted, then it's up to you to pose the question in a way that leads to only 1 solution even if that solution is not the best or proper way to accomplish the task.

As it turned out here, the cause and solution to the problem had nothing to do with Perl, but Perl could have been used to automate the solution.

When the language and documentation are strictly enforced by a single enterprise, like Microsoft or Apple, then there is generally only one real answer, and in general the suggestions that are offered will at least compile and run.

Perl's general philosophy (and possibly most important tenet) is that There Is More Than One Way To Do It ("TIMTOWTDI"), just as there are many differents ways to express something in English (or whatever is your language of choice). The Perl communauty is a universe of freedom (even though thare are ways of doing things which are better than others). You are even welcome to do it in another language than Perl if you think it is more appropriate to your specific problem.

And, while Perl is by far my favorite language and the one I know the best at this point, I am also writing regularly or from time to time programs or scripts in at least two dozens other languages including Unix shell, awk, sed, SQL and PL-SQL, C, R, Fortran, VMS DCL, Javascript, PHP, Java, C++ and others that you probably never heard of, not to speak of others I have used in the past (Modula, Pascal, Delphi, Ada, various brands of Basic, Caml, Clipper, DB3, Lisp, TCL, Python, etc.). Now, if you prefer the straight jacket "enforced by a single enterprise", it is up to you.

The great thing about Perl is that its other main tenet, "do what I mean" (DWIM) means that I was able to write a real professional program in Perl within one day after having spent just two or three days (probably not more than 6 to 8 hours) on a tutorial. My first real Perl program was probably very clumsy, I would certainly not write it the same way today and even less publish it here today, but it worked fine and did what I needed, and and it did it fairly efficiently in view of the very large volume of data it was supposed to process and reformat.