Information: I suppose you've seen this dark box appear around a link when you click it on an iPad/iPod/iPhone. If not, click a link, and you'll see it appear and disappear when the new page has loaded.
I have a webapp that is going to be used on all platforms. I use p-tags as links because I don't want a lot of the a-tag default functionality and appearance, and the links are executed via JavaScript.
The problem is that even though I use p-tags, the iPad displays this annoying dark box around the link when you click on it. The dark box is useful to tell the user that they actually managed to click the link while the next page loads, but this webapp loads stuff from localStorage, so there is no need to have this box that clutters the GUI...
How can this box be removed?
Your reason to use paragraph (p-tags) for links is completely a mystery to me. You can control styling via CSS, no matter what tag it is. P-tags are for paragraphs, A-tags are for links. That's the most basic thing in HTML semantics I can think of.
The box you are refering to is "-webkit-tap-highlight-color"
See http://css-infos.net/property/-webkit-tap-highlight-color
In JavaScript when I open a popup I can disable the adressbar, so the user can't enter something.
Is there a similar option to disable the adressbar in gwt?
Short of doing exactly that same thing and loading your GWT app within that popup window, no. You could potentially have a page that is NOT part of your GWT application open a new window with whatever options, then set the URL of that window to your GWT app's address. There's no way (AFAIK) to hide the address bar in the current window.
I have not worked in this area much. Actually I could not understand whether you are trying to disable the popup's address bar or current parent window's address bar.
But what ever is possible in javascript that can be done in gwt. So if you know what to do using javascript for your requirement then you can go for JSNI. No need to look for GWT based solution.
Between I like your stackoverflow display name :-)
Thanks
When to use HyperLink and when to use Anchor?
When using HyperLink how to handle clicks?
com.google.gwt.user.client.ui.Hyperlink.addClickHandler(ClickHandler) is deprecated
com.google.gwt.user.client.ui.Hyperlink.addClickListener(ClickListener) is deprecated as well.
Doc suggests to use Anchor#addClickHandler, but how to use Anchor#addClickHandler when using HyperLink
Does it mean that if I need to handle click I should always use Anchor and never use HyperLink?
Great question, because it is so simple, and yet opens up what might be a whole new area for a lot of GWT programmers. I've up-voted the question just because it can be a great lead-in for people exploring what GWT can do.
Anchor is a widget for storing and displaying a hyperlink -- essentially the <a> tag. Really not much more exciting than that. If you want your page to link to some external site, use anchor.
Links are also used for internal navigation. Let's say I have a GWT app that requires the user to login, so on my first panel I put a login button. When the user clicks it, I would display a new panel with widgets to collect the user's information, code to validate it, and then if validated successfully, reconstruct that first panel the user was on.
Buttons are nice, but this is a browser, and I want my user's experience to be more like a web page, not a desktop app, so I want to use links instead of buttons. Hyperlink does that. The documentation for hyperlink describes it well:
A widget that serves as an "internal" hyperlink. That is, it is a link
to another state of the running application. When clicked, it will
create a new history frame using History.newItem(java.lang.String),
but without reloading the page.
Being a true hyperlink, it is also possible for the user to
"right-click, open link in new window", which will cause the
application to be loaded in a new window at the state specified by the
hyperlink.
That second sentence should help clear it up. The hyperlink is not changing the page in a URL sense (the way anchor does), though the URL will reflect the state of the program by displaying the "token" associated with the hyperlink appended to the base URL after a slash. You define the token. It would be something descriptive like "login" or "help" or "about". But this isn't a new page. There is no additional HTML file you've had to construct to display a help page, for example. It is the state of the current GWT app that is changing. Even if you "open in a new window" you are just running the same app in a particular state.
It looks like a link, but it is really a widget that manipulates the history frame, which in turn allows you to move the state of your GWT application. You don't write a click handler for the hyperlink widget, but a value change handler for the history stack. When you see that the "help" token has been put on the history stack, your handler will execute GWT code to attach to the RootPanel a FlowPanel with embedded HTML text with your help information. This is perceived by the user as a "new page", which is what he expects when he clicks on a hyperlink. The URL will be something.html/help. Now pretend he returns to this URL via the back button, not your hyperlink. No problem. You don't care about the hyperlink click. You only care that, somehow, the history stack changes. Your value change handler fires again, and does the same thing as before to display the help panel. The user still enjoys the experience of navigating through web pages, even though you and I know that there is only one web page and that you are attaching and detaching panels to the RootPanel (or whatever scheme you are using to display your GWT panels).
And this leads to a bonus topic.
This bonus is a bit more complicated, but ironically, it could help better understand hyperlinks. I say more complicated, but really, it helps solidify this notion that a GWT application is made up of a series of states, and that the web page on the screen is just the user's perception of those state changes. And that is Activities and Places. Activities and Places abstracts away this history frame manipulation, handling it in the background once you've set up a mapper with a GWT-provided class designed for this purpose, allowing you to break down your app into a series of activities, and as the user interacts through these activities he is put into different places, and each place has a view. Moreover, the user can move from place to place using browser controls like the address bar, bookmarks, history, and the backward/forward buttons, giving the user a real web-like experience. If you really want to get a grip on the conceptual difference between hyperlinks and anchors, you should try to learn this GWT topic. It can really make you change the way you see your apps, and for the better.
Hyperlink (or InlineHyperlink) is basically no more than a kind of Anchor with a ClickHandler that calls History.newItem and preventDefault() the event (so that the link is not actually followed).
Actually, Hyperlink won't do that if it thinks (and yes, it's only a guess) you right-clicked or middle-clicked (or ctrl-clicked) on the link (depending on the browser), to open the link in a new window or tab.
If you need any other behavior, then don't use Hyperlink and use Anchor instead. And if you want to add some behavior to an Hyperlink, then use an Anchor and mimic what the Hyperlink does. And you can reuse the HyperlinkImpl to have the right-click/ctrl-click handling (see links below).
But actually, if you need something that looks like a link and do something on click, but does not have a "target URL" (i.e. it shouldn't be right-clicked/ctrl-clicked to open in a new window/tab, or it wouldn't mean anything to do so), then do not use either an ANchor or Hyperlink, use a Label of whatever instead, and make it look like a link (but well, maybe you should use a Button and have it look like a button then; Google used to have link-alike buttons –such as the "refresh" link/button in GMail– and changed them to look like buttons when they really aren't links).
See also https://groups.google.com/d/msg/google-web-toolkit/P7vwRztO6bA/wTshqYs6NM0J and https://groups.google.com/d/msg/google-web-toolkit/CzOvgVsOfTo/IBNaG631-2QJ
I have written an panel which supports file / image uploads. So the panel is a simple plain form. The panel works in a normal Wicket page.
What I would like to do now:
I would like to use the panel in a modal window. The panel is displayed correctly. However, when I submit it / upload a new file, my browser prompts whether or not I would like to leave the page. The page which contains the DIV of the modal window is a form itself.
My research didn't turn up any interesting information about forms in a modal window expect it has to be self contained (nested form). I think this prerequisit is met.
Is there any information available, what I have done wrong? Any tutorials?
You need to use an AjaxSubmitButton (or AjaxSubmitLink) to submit your form. The problem is that the modal window requires Ajax communication. If you use the window to just reprocess a whole page and don't care about the Ajax'ness, then you can override the ModalWindow#getCloseJavaScript() method.
As Martijn pointed out, the modal window relies on AJAX communication. So use AjaxSubmitButton or equivalents. When components in the main window need to be updated after the submit of the modal window, this can be done by adding them to the AjaxRequestTarget.
However when it comes to multi part forms (file uploads) this does not work quite. Apparently multi part doesn't play nicely with AJAX. One has to do an IFrame trick as pointed out e.g. here: http://www.dooriented.com/blog/2008/04/23/wicket-ajax-like-file-upload-on-a-modal-window/
I’m working on an interface in VB6 to interact with a sound editor to automate certain tasks mainly using the editor’s object handles and activating them through SendMessage/PostMessage. In general it works OK, except that the editor has some dialog boxes that open in modal mode and freeze everything on the interface, including the timers.
Is there a practical way to get these dialog boxes to open modeless or to interact with them from the interface after they pop up? I tried an MDI form, but it also freezes along with everything else. The only way to override the modal mode of these boxes is to launch an independent applet beforehand to address the dialog boxes with a timer, but the process is somewhat cumbersome.
All I need to do with the dialog boxes is click the OK button or hit the return key.
The Form.Show method excepts an optional style parameter that determines if the form is modal or modeless. You can pass it the intrinsic constant vbModeless.
Form1.Show vbModeless
It's a difficult question to answer without understanding the context of the dialog boxes. However, if you don't want the dialog to stall the execution of your program, I think the only way is to run your app from a different thread (start and Active X exe or something) and then make calls across to the other thread.