|
You might start here.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Hi,
I have a dialog form inside a pane that has a popup menu which messages are handled in the CMainFrame. I am doing this because the same menu exists also in another pane.
In this case, the acceleratos of the Dialog's popupmenu are hidden since the MFC framework does not "see" any message handlers inside the dialog. The messages as I said before, are handled in the CMainFrame. The accelerators itself works just fine, the only problem is that does not show up in the screen to inform the user.
So, how to force MFC framework to show the dialog's accelerator keys ? I tried to add message handlers in the dialog class but it didn't worked.
sdancer75
|
|
|
|
|
Going on a screen-shot in this article: An examination of menus from a beginner's point of view[^]
Particularly, this image: http://www.codeproject.com/KB/menus/MenusForBeginners/MenuItemEdit.jpg[^]
You can see that adding a tab character and then the text to indicate the accelerator is the way it's done.
So, to make a menu item that says "Bold" and indicates the functionality can be achieved by hitting Ctrl-B, I'd use the text "Bold\tCtrl-B". Unlike the use of the & character to underline the following letter _and_ make the folowing letter actually work, with accelerators, you have to add the text and the accelerator yourself in 2 steps. One as I mentioned, by adding a tab separator between the main text and the accelerator text and the other, by adding an accelerator table,as you've already done.
"When I was 5 years old, my mother always told me that happiness was the key to life. When I went to school, they asked me what I wanted to be when I grew up. I wrote down 'happy'. They told me I didn't understand the assignment, and I told them they didn't understand life." - John Lennon
|
|
|
|
|
Hi,
You may did not understand the problem. The menus are created dynamically and they have their accelerators shortcut keys as declared below.
VERIFY(popmenu.CreatePopupMenu());
popmenu.AppendMenu(MF_STRING, ID_MENU_STRETCH_NORMAL, _T("&Option 1\tAlt+1"));
popmenu.AppendMenu(MF_STRING, ID_MENU_STRETCH_MAX, _T("&Option 2\tAlt+2"));
The problem is that when the popup is showning up to the screen, the acceleratos keys are hidden for the reason I explained in my first post.
Regards,
sdancer75
|
|
|
|
|
sdancer75 wrote: Hi,
You may did not understand the problem.
Hi,
Yes, I think that is true.
If I understand correctly, the accelerator 'hints' on the popup menu are fine. However, when the popup is displayed, the accelerator hints of the dialog are hidden.
If so, I'm still not sure I understand what the issue is - i.e, a popup menu has the keyboard and mouse focus until it dissapears. It is the WindowProc of the popup that receives all input, so in that case it seems to me, that displaying the accelerators of the dialog would not be useful.
However, you've already mentioned that the accelerators are working correctly. This, combined with the thread title and your last post leaves me confused as to what your intentions and problem are. 
"When I was 5 years old, my mother always told me that happiness was the key to life. When I went to school, they asked me what I wanted to be when I grew up. I wrote down 'happy'. They told me I didn't understand the assignment, and I told them they didn't understand life." - John Lennon
|
|
|
|
|
enhzflep wrote: If I understand correctly, the accelerator 'hints' on the popup menu are fine. However, when the popup is displayed, the accelerator hints of the dialog are hidden.
That's correct.
By default if you start a new MFC app and you create a menu that have some acceleration keys, if you are not handling in some way their messages ie loading the accel table, then it automatically disables them.
The problem is that I handle the accel keys not in the dialog but in the MainFrame where the same menu also exists !!!
Regards,
sdancer75
|
|
|
|
|
Hi,
Microsoft has pulled the carpet from underneath me too often. I am now seriously considering going to Linux. Windows 8.XX is entirely incompatible with providing software for a cash register program. WinXP SP1 was perfect for same, As is MFC42 and VC5.00.
Are there equivalents for the same environment for Linux.
Managed Code is an un acceptable alternative. Internet access by the end product is not required.
What is the closest development environment in Linux, to VC 5.00
Regards,
Bram
Bram van Kampen
|
|
|
|
|
Netbeans or Eclipse
.'\ /`.
.'.-.`-'.-.`.
..._: .-. .-. :_...
.' '-.(o ) (o ).-' `.
: _ _ _`~(_)~`_ _ _ :
: /: ' .-=_ _=-. ` ;\ :
: :|-.._ ' ` _..-|: :
: `:| |`:-:-.-:-:'| |:' :
`. `.| | | | | | |.' .'
`. `-:_| | |_:-' .'
`-._ ```` _.-'
``-------'/xml>
|
|
|
|
|
You may also consider Codelite[^] and even passing to Java programming language.
THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?!
-- C++ FQA Lite
|
|
|
|
|
Thanks,
Java is something I would never consider. The suite is leased by customers under an annual licence. Distributing Java Code would jeopardise revenue collection because of easy decompilation. CodeLite merits further investigation though.
However, The entire project consists of 1100 Files, roughly 900 of these relate to MFC, the remaining 200 relate to Non MFC CPP Classes, or, to plain 'C' Code. Hence, I am looking for File Conversion(and not of the video type) This can range from a set of suitable and crafty '#define'S to the writing of a parser and code generator.
The project started in earnest in 2001 on Win98 Architecture. The existing Code Base is considered 'Bug Free' since 2005.
Bram van Kampen
modified 17-Sep-14 19:55pm.
|
|
|
|
|
If you have a lot of existing MFC code, wxWidgets is really modeled to be similar (actually not sure if it was modeled on MFC or it just sort of evolved similarly).
|
|
|
|
|
 Wx would have been my suggestion, too.
A gui I have with custom controls and drawing works equally well under XP, Vista, Win7 and linux. On hardware as varied as a q8400, i3, i7 and a raspberry pi. Simply build for the appropriate platform and voila! Portable, consistent code/gui.
"When I was 5 years old, my mother always told me that happiness was the key to life. When I went to school, they asked me what I wanted to be when I grew up. I wrote down 'happy'. They told me I didn't understand the assignment, and I told them they didn't understand life." - John Lennon
|
|
|
|
|
Bram van Kampen wrote: Windows 8.XX is entirely incompatible with providing software for a cash register program.
(just curious)
In what way? it does not make sense; usually, hardware like that have their own "OS" (and it is usually not Windows)
AFAIL, MFC has not changed since the 2008 feature pack.
Are you using a proprietary SDK/OS for the cash register machine ?
I'd rather be phishing!
|
|
|
|
|
Maximilien wrote: usually, hardware like that have their own "OS" (and it is usually not
Windows)
Not true at all... a bunch of POS systems run on Windows. Of course, a bunch others run on Linux... so it just depends on the manufacturer.
|
|
|
|
|
I stand corrected.
but if POS' OS is windows, than it will probably will not allow be be replaced by linux. (or the other way around).
(just askin')
I'd rather be phishing!
|
|
|
|
|
The POS software is simply just that... software. It runs on a standard computer. Again, depending on the manufacturer, the computer can be a standard computer (since they're relatively cheap) or a smaller form factor embedded computer with a screen (those can be really cheap, have a smaller footprint).
Since it's just a computer w/ software, it can be hosted on whatever OS you want as long as you've built it that way. If you have full-blown Windows on a machine, odds are it's a bigger machine, because most small-form factor embedded computers don't have that much RAM.
Some places may even still be on Unix systems. The big companies are slow to adopt changes and their Unix systems worked so well they've been hesitant to change. I believe Home Depot may still use Unix systems. They're fast and are all linked together so they can track everything based on their databasing of collected data.
|
|
|
|
|
fair enough.
I have to say, I never really looked at the POS to know better!!!
Thanks.
I'd rather be phishing!
|
|
|
|
|
I've worked on embedded systems... so as an engineer (and nerd) I pay attention to what OS's things run on.
|
|
|
|
|
Albert Holguin wrote: Not true at all... a bunch of POS systems run on Windows
Actually I would suspect that the vast majority of POSes run on either windows or a unix variation. Even if one includes systems going back 20 years I would expect that probably at least 90% run one or the other.
|
|
|
|
|
Not sure how your statement differs from what I said...
|
|
|
|
|
You statement could have been taken to mean that even though there was a significant number on Linux/windows, but there could have been others on something else. And this could be a fairly recent development.
But instead almost all of them all windows/Linux and have been for a long time. And I only say almost because it is possible there are some. Although I suspect very few in the US.
|
|
|
|
|
I guess you didn't read the plethora of other posts I wrote? 
In any case, we're not in disagreement.
|
|
|
|
|
Maximilien wrote: In what way? it does not make sense; usually, hardware like that have their own "OS" (and it is usually not Windows)
Well, our existing App runs on XP.
Laundrette and Drycleaning POS systems are far more complicated than say your average Corner shop POS. The latter deals in Commodities. (A Packet of Branded butter is the same as the Next one. We don't care which particular package leaves the shop, or, who walks out with it, as long as we get the money, and update the stock.) In a laundrette, every customer wants their own shirt back, and, we need to know who did what in case of complaint. So a laundrette POS System comprises indeed of the functions of a traditional POS system, such as keeping track of cash and cash drawer contents. In addition to this, the POS System needs means to identify customers, and to book in customer orders, and prioritize these. The staff doing the actual work need a way to find out which orders are at hand, and a way to mark these orders as 'Completed' Management needs statistics. Personell needs records of Production in order to calculate Staff production bonuses, etc, etc. We are talking 'Database Management'
Our system consists of a suite of a bakers dozen interlocking applications. The lot works well in Windows XP. In fact, there is nothing that either Vista, Win7 or Win8 has to offer that would be of any benefit to our system.
The Software is written to be used by staff which are employed because of their Laundry skills, not their computer skills. Any change in IDE experience constitutes a major re-training exercise for all users. The presence of 'charms' and 'Apps' on a Win8 system constitutes a real problem in this respect.
Our suite runs under MFC42, and does not need any of the further extensions introduced in 2008
Hope I satisfied your curiosity.
Bram van Kampen
|
|
|
|
|
Bram van Kampen wrote: Are there equivalents for the same environment for Linux.
For developing GUIs? ...there's a bunch of frameworks out there. A few are Qt, WXwidgets, GTK+. Of course, some of those frameworks are much more than GUIs nowadays (much like MFC). Qt seems to be pretty prevalent in business applications, but if I remember correctly, as a business user you have to pay some fee.
As for non-gui elements, the boost library offers quite a selection of nice cross-platform libraries. If it's in the new C++ standards, it was likely in boost first. 
As for IDEs.. there's a handful to choose from there:
0. Eclipse- Probably one of the most popular, install CDT version (comes with C/C++ plug-ins preinstalled). Bad thing is that Eclipse runs on Java so you'll be running Java to code your C/C++.
1. Netbeans- Probably second most popular. Nice interface, probably "lighter" than Eclipse.
2. CodeBlocks- I've never used this one, but it seems to also have a following. It's probably more bare bones than the others.
3. Others? Run off the terminal?- There should be plenty of choices for coding in C/C++.
|
|
|
|
|
While it is true that XP has gone away, the componentized point of sale version of Windows XP - called "POSReady" will continue to be supported for some time.
http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=POS&Filter=FilterNO
You're good until 2019.
modified 17-Sep-14 15:07pm.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
