I'm fairly new to Xcode and Cocoa/Objective-C and I'm trying to implement something as simple as a QInputDialog that can be re-used throughout the program - with a unique message to the user each time it is launched and return a string as a result.
I have searched the web and found multiple methods but nothing seems to be quite clear or concise - well enough for me to understand anyway.
Is there anything out there as simple as:
Create/Launch a window from a method with a new message label to the user in the form of a string.
Has an NSTextField to receive the users input.
Close the window and return the string from the text field (if accepted) to the calling method.
??
Modal prompts for input are very un-Mac-like. It's like smashing the user's face in with a cricket bat and yelling “TELL ME THE ANSWER NOW!”
The correct solution is to put your text field into a non-modal window, so that the value is already ready when the user invokes whatever action needs the value. Beep and show the “hey, you forgot this” icon if the user hasn't filled in the field and you need a value there. If the field is not relevant in the window the user starts the action from, or if you're going to need several facts as input, then show another window, non-modally, with its own window controller, to take in all the input you'll need for the action.
A separate, non-modal window will also enable the user to fill out and/or perform multiple such actions in parallel.
If you must demand the value with a modal dialog, you can and should make it a sheet, but you'll still need to build the panel and its contents from scratch in IB or code.
See also the Sheet Programming Guide and the chapter on windows in the Human Interface Guidelines.
Related
I have my form with a menu bar and space underneath to display my controls. One of the buttons in my menu bar is suppose to be a print button that prints a graph that's currently in a User Control I display in the form. If the graph was on the form in the print button's eventhandler I could just simply call
graph.printing.print(true)
which isn't going to work in my case since the graph is in the control and not the form.
How do I communicate with a User Control from the containing form and access or pass its variables when needed? I also have a status bar on the bottom of the form which would also need to get updated from the User Control, but I'll be able to deal with that if I got help with just this one part. Please bear in mind, I also have another User Control I'm going to add to the form which will also contain a graph which will need the same treatment as the other graph on the first control when the print button is pressed. I plan on swapping these two out so I have one form displaying one control at a time.
I got this idea from this answer: https://stackoverflow.com/a/18191630/2567273 but after further research I can't find anyone asking about the actual communication process between a form and the control it contains.
I think this answer is close to what I'm looking for, but I think it's leading me down the path to using panels instead of User Controls.
After typing this I noticed the closest answer to my question may be this, but that question has the child raising events and the parent responding while I have the parent raising the event and the parent has to get information from the child.
One way to think about this is Roles. Presumably you built this UserControl to handle the management of the data related to the graphs. As such you can think of them in the Role of a Graphs Specialist . Once you do that, printing them is actually just one more thing it should perhaps do.
The form on the other hand, is not special just because it happens to get receive the command from the user to print. Its role in this might simply to be to know which usercontrol to contact and which method to invoke:
Sub PrintGraphMenuClick....
Select Case something ' determinant as to which UC to contact
Case operation.Foo
ucFoo.PrintGraph
Case operation.Bar
ucBar.PrintGraph
Other menu options like Clear, NewGraph, Save and whatever else there is somewhat the same way. The Form's Role here may be to receive the command from the user and pass it along to the right control, invoking the correct right method and passing the correct parameters - that is not a trivial task.
Of course, rather than a MainMenu, the usercontols could alternatively implement a ContextMenu and even receive those commands directly.
Very often offloading an operation to something else results in so many properties, filenames, streams etc having to be moved from here to there that it becomes burdensome. In this case it is not like the MainForm has some special ability regarding printers that the UserControl cannot handle.
There is only one right solution:
1) Add an event to your user control.
2) Raise the event when the particular "thing" happens in the user control.
3) Attach a handler to the event in Form code.
4) Add code to update the bottom bar in the event handler.
I had a question about Dialogs in VB.NET. I am working on a point of sale program, and at one point during a sale, I have a few windows that pop up. For example, a user will go into a sale that is window A. In window A, they have the option of entering products, etc., and if they choose a 'repair' product, it opens window B, allowing them to choose options. In window B, there is a button that pops up window C that allows them to attach products TO the repair. My issue is with window B opening window C.
Because I open window B as a Dialog (in order to check if DialogResult.OK is true), any window I open with B is non-touchable, as B is a Dialog and requires attention before going to any other windows/forms.
My question is - is there any way to still use a dialog, but allow for manipulating other open forms while the dialog is up, and if not, what would be the best way to check if the user selected OK, or cancelled out of the window?
The only solution I can think of right now would be to open window C as a dialogue as well (it's actually a UserControl, and I'm still trying to find where in the code it's actually getting openned/called), or to create a variable that is passed in to the form, and then passed back out when it's closed, that basically sets a flag to either continue or cancel...
Any advice/ideas??
If I were to explain this using code, this answer would be very long, so instead I'm going to give you a high level overview.
.Show() vs .ShowDialog()
The link below will take you off to Microsofts website to explain the technical differences between these two. However in laymans terms, .ShowDialog() will create the form where it is the only window allowed to have focus in the application. Forms that are called in this instance are hierarchical, in that if you open them in order of 1,2,4,3 then they must be closed in the 3,4,2,1 order. Forms that are opened with just .Show() can be focused at any time.
How to: Display Modal and Modeless Windows Forms
Form.FormBorderStyle property
This property controls how the OS will display the window. The different options under this selection changes the way the window behaves. Depending on the options that are chosen you can make a window that only has a close button on it, or it may not even have a title bar at all. Setting this option to None will take away all controls of the form and only leave you with the Me.ClientArea to work with. When you want a completely custom GUI, this is how you do it but you have to implement your own controls for everything, closing the form, size handles, the ability to move the form on the screen, etc...
Form.FormBorderStyle Property
Passing data between forms
When someone asks how to pass data back and forth between forms, they are usually talking about modeless forms that were created using .Show(). The most common thing I see on SO is to use the tag property of an object (a form is an object that has this property too) to pass data back and forth. While I won't say this is a bad practice, I will recommend creating public properties on your forms. These can be set from a separate form and you can perform additional actions when setting the values (be careful though, this way of doing things isn't thread safe). If you are using a Modeless form as though it were a Modal form, then you can simply override the .Dispose property to return a value or you can create a method named DialogResult that will return the value you need. The caveat to using a DialogResult or similar method is that if the form has been disposed then you can't access the value you wanted to return.
You can use myNewForm.Show(Me) for the Window you want to be shown as a dialog. This will show myNewForm as a child of the current form, but lets you interact with the current form.
I am writing a Windows Forms application in VB.NET. I have three forms: the main form, which shows a list of accounts, the account form which allows the user to view/edit the information for a specific account, and the policy form which allows the user to view/edit the information on a specific policy for that account. I want the forms to appear as if they are all the same window. Example: when the application starts, the user clicks an account name in the list box on the main form and clicks "edit". What I want to happen is that the window stays in the exact same place and stays the same exact size, only the content of the main form appears to be replaced with the content of the account form. Same thing if the user then chooses to edit a policy from the account form. When the user finishes and clicks "save", the main form comes back up. Through this entire use case, it would appear to the user as if they were viewing the same window the entire time, with the content of that window changing.
How can I do this? I have tried something like:
Dim newForm as New AcctForm
newForm.Location = Me.Location
newForm.Show()
Me.Close()
The problem is that if the user moves the original window, the new window appears where the parent form originally appeared, not where it ended up.
I see this is already in the comments, but what I have done in this case in the past is build each "form" in the application as a custom control. Then I have one actual form, and navigation works by changing which custom control is currently loaded on the parent form. To move from one screen/view to another, you remove the current custom control from the form's controls collection and add the new custom control.
I believe this is superior to manually setting the startup position and size, because you can use the form's .SuspendLayout()/.ResumeLayout() methods to hide the interim state, where there is no control loaded, from the user. This is harder to do when you want one form to be completely replaced by another.
This also makes it easy to set certain form properties in one place and have them be consistent for the application. You can even have an area on the form with controls that will now show in every view.
When using this pattern, I typically have each of my custom controls inherit from a common base. You may not have anything specific you will do with that base at the outset, but it almost always comes in handy later.
Finally, switching to use this scheme is easier than you think. Just go to the code for the each of your current forms, and you will find that each class currently inherits from System.Windows.Forms.Form. Most of the time, all you really need to do is change them to inherit from System.Windows.Forms.Panel and you're most of the way there.
As others have said, it may be better to redesign your application using custom controls or panels etc.
However, to answer your question regarding the seemingly random location of your forms, the first thing to check is that each form has it's StartPosition property set to Manual.
If your main form is resizable, then I would also add code to adjust newForm to the same size too.
I hope that helps with your immediate issues; so that you can move on to redesigning the application!
good morning there is another way . set property for second form to (top most) and use also
from2.show();
that make you switch between forms and keep form2 top other
Thanks
try using ShowDialog()
Dim newForm as New AcctForm
newForm.Location = Me.Location
newForm.ShowDialog()
Me.Close() <-- removed this
I have a modal dialog thats building a string. The string is shown to the user, and the user presses checkboxes, radio boxes, etc to build the string. The string exists nowhere - I build it for display in -()builtString; from the configuration of the self.valuesDict.
I can easily wire up the checkboxes via bindings in IB: for example to the files owner (the controller) with self.valuesDict.checkbox1
Also I bound the display of the string to "self.builtString".
But every time any checkbox changes, I want to redisplay the string that's shown to the user.
If I abandon bindings, then I think I can use the [self willChangeValueForKey:#"builtString"], for each checkbox, etc, I think, but that is some messy looking code by the time I deal with them all.
So how do you tell a nstextfield in IB to update every time say self.valuesDict changes?
Thanks for any comments/suggestions.
--Tom
You can specify dependencies between bindings. Just write a class method +(NSSet*) keyPathsForValuesAffectingBuiltString that returns a set with all key paths of properties builtString depends on. Then things bound to your string will also be updated when one of the other properties is changed. For more details and step-by-step instructions you can look at this article.
In my GWT project, I'm trying to get it so two DialogBoxes can pass information between each other. One of them holds a MapWidget, and when a button is pressed in the other DialogBox, the position information is received from that other DialogBox's MapWidget. Does anyone have any tips for how I should coordinate between having two different DialogBoxes show up? Should I wrap the code for the two in a Composite? Furthermore, is there an example anywhere of dealing with two DialogBoxes at once in GWT? For example, if I click outside of the two boxes, both should be dismissed. I'm wondering if there's a way to keep both of them in focus at once, so I can switch between the two without causing either to disappear.
Sharing Data Between Dialog Boxes
In my opinion, the "correct" way to do this would be to implement some sort of MVP structure in the application so that a presenter manages the view (DialogBoxes, among other things) and knows how to pass simple data to the view for it to display (the presenter would handle the MapWidget data, the view would take care of displaying it on the DOM).
However, if you're looking for a quicker/more simpler approach, you have a couple of options (which you choose really depends on the application structure):
Create a Composite, as you mentioned, that knows how to pass the necessary data back and forth. By having the Composite manage the data object and tell the two DialogBoxes how to display it, you are actually approaching an MVP architecture within your Composite.
Subclass DialogBox into a class that contains a HandlerManager (sometimes used as an "Event Bus") that fires events when the button is pressed. You can create events that are designed to pass data back and forth between the two DialogBoxes (even make them type-safe with type parameters). See this StackOverflow question for details on using a HandlerManager. The MVP article, linked above, also has some good information on using an event bus.
Model-View-Presenter is a tried-and-true method of structuring an application that results in more testable code, better project structure, and can help guide you when making decisions like this. I strongly recommend checking it out if you haven't already.
Sharing Auto-Hide Functionality
GWT's PopupPanel (on which DialogBox is based) offers a method addAutoHidePartner(Element) which is describe thusly:
Mouse events that occur within an autoHide partner will not hide a panel set to autoHide.
So, you can create two auto-hiding DialogBoxes that only close when you click outside both of them (e.g., they do not close when you click within either of the boxes) with the following code:
// Create the dialog boxes
DialogBox dbox1 = new DialogBox(true, false);
DialogBox dbox2 = new DialogBox(true, false);
// Set some visual options
dbox1.setPopupPosition(10, 10);
dbox2.setPopupPosition(200, 10);
dbox1.setAnimationEnabled(true);
dbox2.setAnimationEnabled(false);
// Set the dialog boxes' caption and content
dbox1.setHTML("Dialog Box 1");
dbox2.setHTML("Dialog Box 2");
dbox1.setWidget(new HTML("This is the first dialog box."));
dbox2.setWidget(new HTML("This is the second dialog box."));
// Making dobx2 a partner of dbox1 means clicking
// in dbox2 won't cause dbox1 to close
dbox1.addAutoHidePartner(dbox2.getElement());
// Similarly, setting dbox1 as a partner of dbox2 means
// clicking in dbox1 won't cause dbox2 to close
dbox2.addAutoHidePartner(dbox1.getElement());
// Show the dialog boxes
dbox1.show();
dbox2.show();
You can interact with either of the dialog boxes without the other closing. Omit the appropriate call to setAutoHidePartner if you only want a one-way partnership.