Is there a way from the main screen PBO to hide a subscreen field?
The subscreen is defined in a different Function group.
This is not possible: From the viewpoint of the main screen, the subscreen area is just a single element without further internal structure and cannot be examined or modified in detail. You would have to adapt the subscreen program to accept the screen modification data through some more or less generic programming interface and then perform the modification itself.
Here is a possible solution:
If you want to control the visibility of a subscreen field from your main program, you will have to insert a LOOP AT SCREEN in the PBO of the subscreen program, as vwegert has already indicated.
If the subscreen in question belongs to a standard program and you cannot change it for that reason, you may be able to find an appropriate call to a subroute/form from a PBO module of the subscreen where you can insert an implicit enhancement. Inside this enhancement, you can put your code to modify the screen. (Of course, if it is not a standard program, you can just make the change anywhere in a PBO module).
Now, as to controlling the visibility from the main program: In your main program, you can set a flag and export it to memory with EXPORT TO MEMORY. In the PBO of the subscreen, you can then read this flag with IMPORT FROM MEMORY, and depending on the value, hide or show the field with LOOP AT SCREEN.
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 have 20 or so grids in my application suite. I'd like to create a global copy/paste context menu which I can bind to every single grid rather than code in each form.
I am unsure what is the best way to achieve this, I have started to create a class with my menu in it, but get stuck at the point of adding the actual menu options. For example I know I'll need to call a "copy" event, but I also know I'll need to tell it what I am copying, and I cannot see how that is done in vb.net when you can only add the address of a method minus parameters.
e.g.
.MenuItems.Add("Copy Cell", New System.EventHandler(AddressOf CopyCell))
Obviously I want "CopyCell" to only be coded in one place as well, rather than repeated in each form. I will always be copying the same object (SelectedCellCollection).
I am not sure how to make the menu have an event with parameters, or how to make it "know" that I want to always copy the selected items. I'm aware that I'd have to do some coding in the form but just trying to work out the way to minimize it.
I have created my own context menu class (via inheritance) with specific copy and paste functionality / options tailored to the grid I am using. It works fine and only needs one line of code per form/grid to activate.
Take software for a fish merchant.
To sell a certain kind of fish, the UI shows a picture of the fish. The user can click it, then a window pops up in which he can select a different fish.
In a naive implementation, the component needs
access to the FishImageLibrary, to retrieve the image
access to the FishSelectionPopup, to ask the user for a new fish
Solution 1: Pass both classes along.
The problem is that our component can be inside another component. So these two classes would have to be passed along to our component, creating dependencies all over the place.
Solution 2: Callbacks.
Implementation using callbacks wouldn't be very clean either because the component can be inside another component, and the event would have to propagate through the whole hierarchy. This requires changes to several classes.
Any suggestions for a really clean solution?
So, that would be a kind of picturebox displaying whatever fish is selected and opening a selection pop-up when clicked.
I guess that box would be part of a bigger structure whose job is presenting the selected fish. Maybe there's a label with the fish's name, another one that presents the size.. I'd have their parent component set their values when a fish is selected. It would know FishImageLibrary and be able to retrieve the image address based on the fish.
For the pop-up I think the command pattern is pretty standard for this kind of problems. It lets you pass a standardized object to your picture box that won't have to know implementation specifics of OpenSelectionPopup, which itself knows about FishSelectionPopup and how to open it.
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.
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.