Currently I am working on a project that relies heavily on modal dialogs. I'm using durandal's dialog plugin. The problem I have is that within a modal, a user can click an element which displays its details in another modal.
What I would like to do is to close all open modals before I open a new modal. Can anyone give me a good idea of how I can ensure only a single dialog is open at any given time in durandaljs?
Why not use Durandal's pub/sub, or a client-side message bus such as postal.js (which is what we use)? We close all modals by sending a close message over the channel 'app' and the topic 'app/modals'. Instead of holding a reference to an observable (which could have memory implications), we just hold a reference to the message channel (which is a string). Much cleaner way to go.
Ok so the issue I was facing was that I have various Modals, where one modal could be opened from within another modal. However I wanted the modals to close when another would open. The tricky part was that I am using widgets and click events to open the modals.
Since my project is an SPA it occurred to me to simply create a ko.observable - currentModal - on my global object and each new Modal closes the previous, then replaces the old with the new in currentModal(this);
I went even further and am now using the route objects to fire the Modals open as well. Durandal is fun.
Related
Is there a property that tells if a form is deactivated by other form ShowModal procedure ?
EDIT :
My program has a tray icon that brings to front the main form when it's clicked. I want to disable this when another window is shown in modal state. Because not doing so the main form (which is disable) will cover the modal form and completly block my program.
This behaviour is to be expected. When a modal form is shown, the other forms are disabled. You don't need to disable anything at all, the framework already handles it all for you. The beep is sounding because you are attempting to interact with a disabled form.
If you want to be notified when your window has been disabled, for any reason, not just because a modal form has been shown, listen to the WM_ENABLE message. To test whether or not your main form has been disabled. Do that by calling the IsWindowEnabled Win32 function.
Having said that I feel that it is likely you've not diagnosed the issue correctly. It sounds like you might be suffering from window ownership problems, which are common in Delphi 6. Or perhaps you are attempting to restore the application incorrectly from your notification icon code. Use Application.BringToFront for that.
The VCL's handling of modal dialogs seem very mixed up. When you show a system provided modal dialog, e.g. MessageBox, windows are disabled whether or not they are visible. However, the VCL only disables visible windows when ShowModal is called. What's more, you cannot use Enabled to test whether or not the window is disabled, you must use the IsWindowEnabled Win32 function.
You can test Application.ModalLevel at any point in time to find out if there's a modal form. E.g.:
if Application.ModalLevel = 0 then
MainForm.Visible := True;
Note that non-TCustomForm descendants will not set modal level, API dialogs like a file open dialog or MessageBox for instance. If there's a possibility of such a thing, you might surround code that runs those dialogs with ModalStarted and ModalFinished.
It doesn't seem necessary in your case, but if you somehow need to be notified that a form/dialog is going modal, you can attach a handler to Application.OnModalBegin and Application.OnModalEnd events. You can use an TApplicationEvents component for that.
I tried the example which is showing how to get data from history to re-generate UI; The thing I see mostly in all "history usage" examples are related to UI re-generation only so it is none-static way...
But what about "each UI state may have its unique url something like JSF does with flows"? For example I have app url like a
http://localhost:8080/myapp/MyApp.html
the app default UI contains main menu which is helping to navigate through my test catalog; I tried to make possible keep the UI dynamics in history by building url in this way
http://localhost:8080/myapp/MyApp.html#menu_testcategory_page1
but when I click internet browser "refresh" button the url keeps the same as http://localhost:8080/myapp/MyApp.html#menu_testcategory_page1 but the UI comes back to its default state :(
So my question is
is there an optimal way in pure gwt to stay in the same UI state even after browser's refresh button is clicked (I mean the unload/load window events occur)?
thanks
P.S. gwt 2.3
You should implement Activities and Places pattern: http://www.gwtproject.org/doc/latest/DevGuideMvpActivitiesAndPlaces.html
I am using it for 3 years, and it works very well.
Note, however, that when you reload a page, you lose all of your state, data, etc. If you need to preserve some of it, you can use a combination of a Place (#page1) and a token that tells the corresponding Activity the state of the View representing this Place, i.e. (#page1:item=5).
You probably just forgot to call
History.fireCurrentHistoryState();
from your entry point.
I am trying to open a modal window during a click handler to verify the user action but the window doesn't appear until the handler completes. The window code can be as simple as the following and it still will not display so it isn't something to do with my abstract class.
Window w = new Window();
w.setModal(true);
w.setImmediate(true);
// Add components etc etc
UI.getCurrent().addWindow(w);
I could add the action code to the windows OK/Yes handler but that would stop me creating a generic Message class to simplify/stop code duplication.
I am guessing there is something I dont understand about how Vaadin/GWT works (still a newbie!), could someone point me in the right direction?
Cheers
For UI stuff, you have to stop thinking of sequencial programming,
better to think about event-driven concepts.
For Vaadin you could create a Dialog Window which asks the yes/no question.
In you app you create this dialog and display it.
And you attach a event-handler which is fired when the user clicks yes/no,
and inside this handler you then do the required actions in your code.
You can also look at this add-on
https://vaadin.com/de/directory#addon/confirmdialog
The right direction is architecture overview https://vaadin.com/book/vaadin7/-/page/architecture.html#architecture.overview
In other words your code makes only response from server side, but only client side can show "modal" window.
In your case you have to create handler for ok button click event and wait for this event
We use MVP with custom EventBus to navigate across the views. One of our GWT module loads an ebook within a view. We have a button named "Expand", which upon clicked, loads the ebook in expanded mode thereby hiding the header, footer, etc.
Let us say the view (UiBinder) with "Expand" button is named as "ShowEbookView". Upon clicking "Expand" button, the ClickEvent is captured and fired to the EventBus. The logic onExpand(final ExpandEvent expandEvent) is written in the same "ShowExpandedMod" class.
Everything is okay, but we have a button named "Popout" in the expanded mode, which when clicked, should open the Ebook in a NEW page! We need to abstract the "ShowExpandedMod" class so that it can operate with the EbookId and can be used in the new page.
We have created a new Module with EntryPoint class, HTML page and UiBinder page for this new popout window. I am not sure how to proceed now with the abstraction and to use EventBus across different modules to load the same content ... (with re-usability ofcourse)
I've explained to my best, but perhaps not very clear! Please let me know if you want more details.
Thanks!
When you open a new window in browser you basically get a new instance of your GWT app. You can not use EventBus across different browser windows, i.e. across different GWT module instances.
What you can do is:
Add an argument to the Popout page URL. This is easies done via "history tokens" (fragment identifiers), like this http://yourdomain.com/popout.html#theIdOfTheDocument. Then you can retrieve the token via History.getToken()
Use DOM to communicate between browser windows: window.open() in javascript opens a new window and returns a reference to DOM of the new window. You can then access properties and functions of the new window. This is all javascript, in order to make this work in GWT you'll need to wrap it in JSNI.
Try and use MVP4G, in specific - take a look at their multi-modules feature (which utilizes GWT's code splitting capabilities).
This should make things like multiple EventBus's and cross-module event triggers a lot easier to handle.
Is there a function that allow me to select text when the extension
stays open. Normally when I Use the extension popup and I Click outside the
extension the extension close. Is there a wat to avoid this.
Thank you so much
Unfortunately there is currently no way to keep the popup open once you focus out of it. This is by design.
If you would like to always show something while interacting with the page, perhaps the experimental Info bars or even Desktop Notifications would work?
Hope that helped!
The only way to keep it open is to right click over the extension icon (button) and select "Inspect popup" the extension popup then show up and remain open but of course the debugger window show and this not a fix obviously still it will maybe inspire a hack... if someone is skilled enough and share the solution with all of us.
I encountered the same problem and I've thought of a possible solution (though not tested it):
Use your background.html to store the content of the popup action and upon loading the popup, you fetch the content via the default messaging for chrome extensions.
When doing all kinds of other stuff, like XHR's or something, I think you should do that in background.html too, so the requests won't abort if you close and you can do something with the result. Then when a user re-opens the popup, he'll see the result of his previous action instead of the default screen.
Anyone tried something like did already?
As far as I know you can't persist a pop up menu but my workaround has been using a content script to append a menu on page load. After the menu is appended you can toggle the menu via messaging between the background script and the content script.
If you want to encapsulate the menu from the page it's deployed on you could wrap your menu in an iframe. This could add complexity to your project since you would have to deal with cross origin issues and permissions.
There is an alternative hack for this. You can make use of chrome local storage to store the metadata as needed. Upon restart you can read that metadata and render the desired content. You will also probably clear that metadata after you have completed performing the operations based on that.