This question concerns Oracle Forms 10g.
I have a form with two windows. The main form has a main canvas and two stacked canvases. On one of the stacked canvases there are keyboard navigable elements. I also have another window that is used as a calendar data selection. My problem is that when the form loads the calendar window is visible even though I have not explicitly told it be visible. I only want to show this window when a button is clicked so that the user can select a data from the calendar.
I have checked the main canvas and it DOES have navigable elements so I am not sure why the other form keeps popping up upon form load.
Any ideas? I am using Forms 10g
Thanks...
Why not tell the calendar window to explicitly not show up by using the built-in
SET_WINDOW_PROPERTY('W_CALENDAR', VISIBLE, PROPERTY_FALSE);
On the calendar button on your first window you obviously have a WHEN-BUTTON-PRESSED trigger. Place below code at the beginning of the trigger to show the calendar W_CALENDAR window.
SET_WINDOW_PROPERTY('W_CALENDAR', VISIBLE, PROPERTY_TRUE);
Related
Is there a way, after selection of a color, to programmatically hide the color picker of the TComboColorBox? I've searched on the web and Embarcadero community but couldn't find a way to do this.
The answer is no, there is no designed way to hide (collapse) the popup programmatically. And you did not explain why you think it would be necessary to have.
Keep in mind that there are 4 subcontrols, that the user may want to use:
a THueTrackBar,
an alpha channel trackbar,
a color quad, and
a hex color value edit box.
An automatic collapse of the popup would be just annoying.
The user can at any time decide to close the popup simply by clicking on the constantly visible bar.
With reference to your comment:
After your answer, I realized that I must implement a color picker component that shows a rect containing a TComboColorBox and a TButton as childs. Clicking the child button, in turn, hides the container rect itself.
I have told you twice that the user can close the popup part of the TComboColorBox simply by clicking on the component (the base part of it).
In fact, the user can click anywhere outside of the popup window in order to close the popup window. The popup is closed immediately when the focus moves away from it.
In my opinion there's no need for a special "Close" button.
I am creating an event screen like Outlook's. The issue I am coming across is that the autocompletebox I am using from Syncfusion doesn't automatically grow in height as more tokens are added.
The current workflow is exactly like outlooks. When the control is clicked on, it brings you to another page where you can select tokens. On return, the selected items populate the autocomplete circled below.
The approach I currently took is to have a listview. Scrolling is disabled for the listview since the page resides in a scrollview and nested scrollviews aren't recommended for xamarin. The height of the listview is dependent on the number of selecteditems.
I am wondering if there's another approach or control that would be more suited for my situation? Or if someone has come across a autocomplete control where the height will grow.
I have some pages where I have a kendo ui grid (wired up to full CRUD services), but use a separate Kendo UI Toolbar control (as opposed to the toolbar configuration in the grid itself). I have a number of different buttons/menus on the toolbar, but am seeing a strange behavior when calling saveChanges() on the grid. If a cell is being edited when the save button is clicked, the grid is saved, but the edited value is lost (it reverts back to where it was). The following details what I see in different situations:
When using a save button configured in the grid (command: "save"), any changes in a cell being edited are committed with the save.
When using a plain html button that calls the saveChanges() method of the grid, any changes in a cell being edited are committed with the save.
When using a save button configured in a toolbar control, the changes in a cell being edited are LOST when saveChanges() is called.
The following jsbin shows the behavior of all three:
http://jsbin.com/jazobexatu/2/edit?html,js,output
I have tried calling the save from the toolbar button a number of different ways (even trying to trigger the click event of the external button), but nothing seems to correct the behavior. I also tried calling closeCell() on the grid (to try to force the value back into the data, but that doesn't work either). I haven't been able to debug the javascript enough to figure out what is different. I'm hoping someone with a deeper understanding of these controls can help me out.
For some reason, the mouse down event on the toolbar button doesn't cause a blur on the editor.
You can try it yourself by clicking in the cell to edit it, then click and hold the mouse button down on the "normal" button. The editor closes on mouse down, causing a blur of the editor, and persists the change.
If you do the same thing, click and hold mouse down, on the toolbar button, the editor stays open.
I've been poking through the source, but haven't figured out exactly why this happens. My best guess would be that the mousedown handler on the toolbar prevents the event from bubbling or running its default action and the editor doesn't blur.
Additional detail: On mousedown on the grid header button and the normal button, the focused element changes (which is what causes the editor blur). But on mousedown of the toolbar button, the editor input element still has the focus.
Shifting the focus on mousedown of the toolbar might be a workaround.
Sort of a weird hack, but this works in Chrome (any should in any browser that supports activeElement
click: function (e) {
$(document.activeElement).blur();
$("#grid").data("kendoGrid").saveChanges();
}
I have created a custom (themed) NSWindow, by creating a borderless window and then recreating all elements of the window border/background inside the content view. I've created the window widgets (close box, zoom box, minimize box) on top of my own fake title bar using -standardWindowButton:forStyleMask:.
Trouble is, when a sheet is presented on top of my custom window (e.g. "save changes...", those buttons do not receive the clicks.
Does anybody know how I can tell NSWindow not to intercept the clicks in my minimize box? It works with a standard NSWindow. When a sheet is up, I can still send both of them to the dock, or zoom the window out.
I thought maybe there's special code in the content view that ignores clicks in subviews while a sheet is up. But it seems as if -hitTest: is called on the content view and returns the minimize widget, but the widget's action never gets triggered.
I guess I could just replace the content view and perform the action in the content view's hitTest if it is the minimize widget ... but that seems a bit ugly.
I got an application which has a NSToolbar in its main window. Depending on which icon is clicked a NSView is displayed in this window. My problem is, that one of these views shows data in a NSTableView that I want to be reloaded each time the view is visible. Since -init is only called once, I don't know how to do that.
(example: When the application starts it shows the Documents section [on of the sub views of the window]. Now when I click on Employees [which displays another sub view instead of the first one] and then on Documents again, I want the data in Documents' NSTableView to reload.)
How do I do that?
Thanks in advance.
I got an application which has a NSToolbar in its main window. Depending on which icon is clicked a NSView is displayed in this window.
Use a tab view. You can hide the tabs, then implement your action methods for the toolbar items to act as the tabs, changing the selected tab view item to whichever one corresponds to the pressed toolbar item.
Now when I click on Employees [which displays another sub view instead of the first one] and then on Documents again, I want the data in Documents' NSTableView to reload.
Why? Why not reload it only when the data changes?
You don't have to hold NSTableView's hand; if it needs the data from you again, it'll ask you for it again.
And if you're concerned about reloading the data while the view is not visible, that's premature optimization. Don't worry about it until you prove via profiling that it is a real performance problem.