I'm creating a program in Visual Studio, and there is a point in the program when the user will have to mark a item in a ListBox and click on a button to change some values to it. Problem is that it works even if they don't have one marked, and then the program will break at the next button press.
if(lbxItems->SelectedIndex < 0)
{
MessageBox::Show("Please choose an item to change");
}
When I do it like this the MessageBox will pop up but the program won't give the user a chance to actually mark an item. I've tried to make it with a do while but then it just spammed message boxes until you stopped the program.
The problems is there to begin with because when they click the "change" button the GroupBox in which the ListBox is located disables, so the user can't do it after.
What I think I'm searching for is a way to pause the program in a do while loop so the user has time to mark an item before it loops it again and spam more message boxes.
I know this might very well be extremely confusing, and if you need more code, there is plenty more that I can show.
Related
When I start up my PyQt GUI, the focus immediately goes to the text box.
I want there to be no focus on any of the buttons at the start of the program, especially not the text box.
Is there a way to remove the focus entirely or at least move the focus to a button or something?
Thanks
clearFocus() seems to work after a certain amount of delay after the window is visible. I also used setFocus() on the QMainWindow and then the textedit field lost focus.
Create a button with dimensions 0 wide by 0 high.
Set it as the default button and also early in the tab order before the other controlls that except focus; but note that it will be triggered if the user presses ENTER in some edit controls.
Call self.ui.yourbutton.setFocus() if desired for example after restore from minimized
If I instantiate a popup button, I can dismiss it by selecting one of the options or by clicking somewhere else. Is there a good way to dismiss it from a script? I tried setting the menuHistory, but it doesn't seem to have any effect.
Mark - if you check the openStacks is the first line empty while the popup menu is displayed? I think it is and then you could test that way.
Answering my own question:
I haven't found a good way to determine whether a popup menu button is displayed yet - none of the usual property checks seem to work. But I sidestepped the issue thusly:
in my scrollwheel handler I
dispatch "menuPick" to button "PluginMenu"
Then in the menuPick handler of the PluginMenu button I have
if pItemName is empty then
lock screen
put word 2 of the selectedline of field "xyzzy" into tLine
select after line tLine of field "xyzzy"
click at the selectedloc
unlock screen
end if
where pItemName is the normal menuPick parameter.
If I could determine when the popup was visible I could limit the menuPick call to just the times when it's on screen, but otherwise the effect is just to click at the end of the line, deselecting the popup if it's on top.
Edit: the scrollwheel handler mentioned above is in the rawKeyUp handler of field "xyzzy".
Edit 2: as mentioned, that should be "rawKeyDown" instead of "rawKeyUp".
And as Trevor mentioned, checking line 1 of the openStacks makes it even better:
if line 1 of the openStacks is empty then
dispatch "menuPick" to button "PluginMenu"
end if
It may be that you need to fake your popup menu with a palette stack which closes on suspendStack. That way there's no blocking involved and you can close it whenever you like. You would need to mess with the focus of the field I think after opening the palette so it still has the focus.
I just tried clicking a button containing the following script then clicking on a popup button.
on mouseUp
set the uActive of me to not the uActive of me
if the uActive of me then send "test" to me in 2000 millisecs
end mouseUp
on test
put the millisecs
if the uActive of me then send "test" to me in 2000 millisecs
end test
The popup seems to be modal and blocks the timed routine in the button script. I'm thinking that Monte's idea of faking the popup might be a good one ;)
You can't access already open menus by script. However, on Windows, if you open the popup menu with the popup command in a mouseDown handler, the mouseDown handler will run till the end instantly. If you use a stack panel instead of a regular popup menu, you might be able to close the stack panel by script (I haven't tried this). I don't think that this is possible on Mac OS X because menus block any currently running scripts until the menu closes.
We have a legacy code MFC VC++ one.
I need to add a message box asking for 2 inputs(both are string).
No need to consider security issue. Just need input.
How to do this?
I am really not MFC guy. Searched several pages. Not good for me.
Best
Thank you
To get input you want a dialog, not a message box.
Assuming you're working in VS, you'll go to the resource view, expand the tree, right-click on "Dialog" and pick "Insert Dialog" from the pop-up menu. That'll let you draw your dialog, where you'll insert a couple of edit controls, probably with a static control next to each to describe what to enter there, etc. It'll start out with Ok and Cancel buttons, so you don't need to add those.
Once you've drawn what the dialog will look like, you need to add some code and such to back it up. Right click on one of the controls, and pick "Add Class" from the menu. That'll bring up a dialog that'll ask for the name of the class for the dialog. You'll enter some class name (e.g., "my_input") and it'll pick matching names for the source/header file. You'll probably want to change the base class from "CDHtmlDialog" to "CDialog". When you're happy with that, click "finish" and it'll create the class/files.
Then you'll go back to the dialog, right-click in one of the edit controls, and choose "add variable". To keep things simple toward the far right, change the "Category" from "Control" to "Value". Then pick a name for the string you'll receive from that control and click Ok. Repeat for the other control. Repeat for the other edit control (obviously choosing a different name for its variable).
The last thing you need to add is some code to invoke that dialog. To do that, you'll need to include the dialog's header in where you're going to use it. Then you'll add a bit of code something like:
my_input inp;
if (inp.DoModal() == IDOK) {
// retrieve your two strings
CString input1 = inp.field1;
Cstring input2 = inp.field2;
}
Language: Progress 10.1C
I have a Windows form, and on it I dynamically create a number of widgets (toggle-boxes in this case). I can create anything from 0 to 64 widgets, depending on how many do-hickies the user has in the current collection. As the user changes from one collection to another, the widgets are deleted or created as needed. The form will resize according to how many widgets are displayed.
The user can check any number of them and perform certain processes on the checked items by selecting actions from a menu bar, toolbar or keyboard shortcuts. But I also want the user to be able to right-click on a single widget, which should bring up a popup menu with actions that can be performed on just the one clicked item, whether it's checked or not.
In itself, this is pretty straight forward. In the past I had done this kind of thing (in other languages) by having a single popup menu that pops up when the user clicks on any one of the dynamic controls. But I'm having a hard time doing this simple thing in Progress:
I am unable to have one popup menu that responds to the right-click of all the widgets. I tried creating a single popup menu, and then as I create each dynamic widget, I set its popup-menu attribute to this menu. The problem is that a menu can only be applied to one widget. Once I've assigned it to Widget1, I cannot assign it to Widget2. This leads one to think of creating a seperate but identical menu for each widget. And as the widgets are destroyed and recreated, so will these menus. In a single session I will create and destroy hundreds or even thousands of these identical menus, while the user might use one of them once or twice. Or not at all. So this does not seem like a good option to me.
My next solution would be to create a single menu which I can pop up programatically, but all attempts to programatically pop up a menu have failed. I have tried APPLY "MENU-DROP" TO MENU MyMenu and other similar things and I cannot for the life of me figure out how to do it. I also find it very difficult to search for information on this. It's as if nobody else has ever tried this, and the rare cases where someone has asked about it, there has been no satisfactory answers. I'm suspecting this cannot be done.
While trying all these things, I have also had endless problems with the events MOUSE-MENU-DOWN, MOUSE-MENU-UP and MOUSE-MENU-CLICK. MOUSE-MENU-CLICK seems to never happen, not for my dynamic widgets anyway. I am unable to figure out why. MOUSE-MENU-UP occurs sometimes, but it depends on what happens in MOUSE-MENU-DOWN and other events of the widgets as well as the widgets' parents. I have not been able to figure out exactly when it will or won't fire, it's very counter-intuitive. MOUSE-MENU-DOWN is the only one I can count on firing.
So: I can't show a menu programatically, I can only show it by right clicking on the menu's parent. The only way to avoid having hundreds of identical menus, is to have a popup menu on the parent of the widgets, for example the default frame.
With a static popup menu on the default frame, I can right-click on the widgets and the menu will come up, but it comes up if I click anywhere in the frame. I can disable the menu, and then in the right-click event of the widget, I enable it. This works very well the first time; if I click anywhere in the frame, nothing happens (the menu is diabled), but if I click on my widget, the menu is enabled and pops up. Yay! But now the menu is enabled and now it pops up if I right-click anywhere, on buttons, empty space, progress bars, etc. When do I disable it again? After the menu has popped up, the user can click anywhere and the menu will dissappear. There is no event that fires when the menu is closed, so I'm stuck.
Sorry about the long ramblings, I'll restate the question briefly: I want to have one popup menu that pops up when the user right-clicks one of a number of dynamically created widgets.
Using Tom's answer, this is how I implemented it:
/* Somewhere in Control Definitions... */
DEFINE MENU m_Popup
MENU-ITEM m_Test1 LABEL "Test 1"
MENU-ITEM m_Test2 LABEL "Test 2".
/* Somewhere, where I need to dynamically create the widgets. */
/* Loop through the items in the temp table and create a widget for each. */
FOR EACH ttItem BY ttItem.ItemName:
CREATE TOGGLE-BOX hWidget
ASSIGN
FRAME = FRAME DEFAULT-FRAME:HANDLE
LABEL = STRING(ttItem.ttItemName)
TRIGGERS:
ON MOUSE-MENU-DOWN PERSISTENT RUN GetMenu IN THIS-PROCEDURE.
END TRIGGERS.
END.
/* If the user right-clicks on any one of the widgets, this procedure */
/* is run with SELF being the widget that was clicked on. */
PROCEDURE GetMenu:
/* Remove the menu from its current owner and assign it to SELF. */
MENU m_Popup:OWNER:POPUP-MENU = ?.
SELF:POPUP-MENU = MENU m_Popup:HANDLE.
END PROCEDURE.
/* The user clicks on one of the menu items */
/* Here SELF is the menu item that was clicked. I can */
/* get m_Popup from SELF:PARENT and the widget it was */
/* was assigned to from SELF:PARENT:OWNER. */
ON CHOOSE OF MENU-ITEM m_Test1
DO:
MESSAGE "You selected " SELF:LABEL " for " SELF:PARENT:OWNER:LABEL.
END.
My buddy Mike Fechner (who is not currently on SO but who does this stuff a lot more than I do) tells me that, while this example is static, something very similar should work:
Procedure getMenu:
DEFINE INPUT PARAMETER phWidget AS HANDLE NO-UNDO.
DO WITH FRAME {&FRAME-NAME}:
FILL-IN-1:POPUP-MENU = ? .
FILL-IN-2:POPUP-MENU = ? .
FILL-IN-3:POPUP-MENU = ? .
END.
phWidget:POPUP-MENU = MENU POPUP-MENU-FILL-IN-1:HANDLE .
END procedure.
ON RIGHT-MOUSE-DOWN of all three fill-in’s you "RUN getMenu (SELF)." to steal the popup menu from whomever has it.
I have an interesting (but frustraring) problem. I have an application which uses the full screen (this is meant to simulate a third-party fullscreen POS application).
My application displays a sequence of modeless dialog boxes on top of the full screen application. It shows one, hides it, then shows the next, hides it etc. After the 3rd show, the Windows taskbar appears about 1 second later. I can't figure out why.
I've stripped my code right back to see if its something I'm doing in my OnNcActivate handler (which I use to draw my skinned window) but I don't think it is as the problem appears to be timing related. I've tried running Spy++ as well as dumping messages in m WindowProc myself and I still can't see anything odd that would give me any clues.
There are some messages with ID 0x36e in my logs but I can't find out what they are supposed to be. I've checked various message ID lists and can't find them. They shouldn't be any message IDs of my own since WM_USER doesn't start until 0x400.
I know I could get around this problem by auto-hiding the taskbar but I can't ask our customers to configure their taskbars to auto-hide to get round my problem.
Any ideas why the taskbar would appear in relation to my modeless dialog boxes?
EDIT: I completely stripped out my self-drawn GUI code and I still have the same problem. I could be wrong but it would seem that when I call ShowWindow( SW_HIDE) first, Windows tries to activate "another Window" (as it says in MSDN). I think in this case its activating the taskbar rather than the POS application. If on the other hand I open my second window before calling ShowWindow( SW_HIDE ) on the second, then it seems to behave itself.
Cheers
Sparky
Following a long discussion I come to the conclusion that DestroyWindow was not the problem. I found in the end that displaying a dialog.. clicking on the POS, then clicking back on the dialog that sometimes the taskbar would appear. I have spent an entire week trying to find reasons for all of this but to no avail. I thought that assigning the POS window as the owner would solve the problem - it didn't. In the end the solution for my problem was to determine if the taskbar is obscured completely before showing my dialog. If it is, I hide the taskbar for the duration which my dialog is displayed (set its placement to SW_HIDE) and then set it to SW_SHOW when I close my dialog. The task bar doesn't pop up and annoy people anymore. Not a fantastic solution for other peoples' applications perhaps, but perfect for our customers.