Whenever I create a new e-mail (new message, forward, reply, reply-all, etc.) I want to have it open up in a specific position relevant to my monitor.
If you push the windows key + right arrow button it aligns the selected application to cover the right half of the monitor (windows key + left arrow aligns it with left half of monitor). I want the new e-mail to open up in this position.
But upon a new e-mail prompting it is just a random size that covers a percentage of the screen.
Tried to look online and through Stack Exchange but this could be one of those "too much efficiency problems" my friends tell me I have.
Thanks for the help!
Use Inspector.Left/Top/Width/Height properties to set the inspector position.
Inspector object can be retrieved from MailItem.GetInspector, Application.ActiveInspector, etc.
Related
I'm working on a GWT application that has the following layout:
- on top there's Menu Bar
- below that screen is separated into two panel by Split Layout Panel
When user clicks on a label in Menu Bar relevant information is show below in the left part of the screen. Then user clicks on an action item on that left part of the screen, and relevant information on that action item is displayed on the right part of the screen.
Clicking on an action item on the right part of the screen may also change relevant information on left part of the screen.
I want to extend on this by giving a possibility to drag/drop the panel on the right part of the screen to another browser tab/window. After that the right and left part of the screen should remain connected as if they are in the same browser tab/window.
Also, that new tab/window should only display that right panel, while Menu Bar and left panel, along with Split Layout Panel should not be present (this is less important but it would be great if it can be done).
Another important thing is that current visual representation of application is not changed but only extended with this functionality.
Is that something that can be done and if it is how to do it?
Thank you for your help.
I think you would have to use "HTML5" native drag and drop to drag between browser instances, so that would limit browser support. Both tabs would already have to have your code loaded into them so they could respond to these events.
If you have a server back end (not just static HTML/JS) then you could communicate via the server. Otherwise maybe "HTML5" client side storage to store blobs of data describing the panel contents. Probably easier re-render in the new browser/tab.
I have a windows 8 grid app, however, when I click on a group, I don't want the GroupDetailPage. Instead, I need a page that has multiple tiles which are clickable links.
Something similar to the app store, when you click a particular group, say Games, you get all the games, arranged in a grid and it is a clickable link.
Any help is very much appreciated.
thanks in advance
You could modify the existing GroupDetailPage removing the content about the group, and leaving just the list of items. Or you could modify the destination of the group heading click to a completely new page that you generate.
Are you using C#/XAML, HTML5/JS?
If you are looking to mimic tile animations and display the MetroJS library is pretty cool:
http://www.drewgreenwell.com/projects/metrojs
I was wondering whether any of you may have an idea how to mimic the behavior of the native Mail app on the iPhone, when selecting email contacts in the To/CC lines.
If you note carefully, when touching that line the keyboard opens and you get a cursor, which is like the normal behavior of a UITextField. However, after keying a name and selecting it, the name is added inside a blue bubble. Still fine - one could create the bubble and move the text field. However, if you go back using the backspace key - the blue bubble becomes marked (darker blue), the cursor disappears, but the keyboard stays visible.
Any idea how to accomplish that?
Thanks!
Ariel
Check out the Three20 control library from the Facebook: https://github.com/facebook/three20
Either the TTMessageController, or the TTPickerTextField control are what you want. For using TTPickerTextField there's a good demo here: https://github.com/shayne/TTPickerTextFieldDemo
I'm having a sort out of my (Delphi) applications and I been visiting the floating form size and location persistence which seems to be increasingly important with larger screen real-estate and multi-monitors. Clearly it is often desireable to have a user's form reopen in the same place as they closed it, but maybe not always, for example a modal dialog might justify opening bang in front of the users vision, i.e on the primary monitor center screen. There seems to be little out there on the 'net about this and commercial applications seem inconsistent especially regarding multiple monitors. So, a few (probably contravertial!) rules to get us started...
Non-modal forms should always reopen at the size and location of closure.
Modal forms (i.e with OK/cancel, Yes/No buttons) should reopen at the
previous size (if sizeable), but inthe center of the monitor on which the application resides.
An information message box should open in the center of the monitor on which the application resides.
A warning or error dialog should open in the center of the primary monitor.
Thanks in advance,
Brian
"Non-modal forms should always reopen at the size and location of closure."
They must have a default position and size when they first open. Do you have
any rules about this?
I would add the qualifier: If the screen resolution/monitor count is
different from the last time this form was opened, then it reverts to default
position. So no inaccessible forms restored 400 pixels to the right and below
the screen area.
"A warning or error dialog should open in the centre of the primary monitor."
I don't understand why you move the messagebox from 'monitor where the app
resides' (henceforth MWTAR) to the primary monitor. You know the punter is
looking at the MWTAR; after all he has just done something 'bad'. Why are you
changing monitors now you have something important to say?
(After all, if it is an error dialog containing useful diagnostics, he won't
read it anyway. I don't see the need to hide it from him.)
A further thought. One problem with error modal dialogs is that, wherever they pop up, the user may hit 'Enter' accidentally while typing something else and dismiss it. I know I do this quite often.
One trick I have seen to overcome this is to disable the Ok button when the dialog is first displayed. There is a 3 second timer in the dialog which counts down, displaying the time remaining in a small label attached to the button. So the punter knows he will be able to dismiss the thing soon.
Obviously this must be used very, very sparingly, and only on the rarest and most important of dialogs. But it struck me as quite clever. Perhaps all that needs doing is to make Ok the default button after three seconds.
A dialog should never open in the center of the monitor. Consider one of the 30" monitors with 2560 x 1600 pixels resolution - using an application maximized on one of these monitors makes sense only in very specific cases. If an application form resides in one of the corners of that huge screen area then the user would need to move the mouse cursor from its current location to the center of the screen, and back after dismissing the dialog. Also, with a normal viewing distance it's probably impossible to have all of that screen in view at the same time, so center of the active window will be more "in front of the users vision" than the screen center. Any dialog that doesn't remember its position should open centered on its parent window. Exceptions should be made for dialogs that are bigger than their parent window (where it makes sense to leave a bit of the parent visible, which makes it more obvious for the user what's going on), and property pages that should appear near the objects they apply to.
I would also think about saving screen positions in percent of the screen area, not in pixels. This way using a laptop with and without a large external screen will always make optimum use of the screen area - using absolute coordinates will either have portions of the screen unused, or windows moved outside of the visible area.
Depending on the platform, when the application does not have focus when throwing up an alert it should avoid taking focus. Too easy for a user typing to dismiss the alert without any chance to read it.
E.g. on Windows make use of the ability to flash a task bar button.
Ok so could anyone please help me out with the VB for auto entering information into a text box, by clicking certian label boxes on a form in access 2003.
I built this thing using label boxes as "sort of links" instead of button for navigation/commands etc, and I have this power point presentation viewer on one of the forms.
The client has numerous briefings and this will be great for me to provide a little something for them to be able to get their briefings from one spot.
So if I list the choices for the month out on the form as label boxes (with little mouse move events to resemble a web link) and they click on it to select, then the only way I know how this may become functional is if I add a text box to the form, and make it not visible, that way I can name it, and add it to the file path string and it works.
But how do I create the action of clicking the "link" result in "NVOWEFDJHF" into text box?
Anyone know a better way?
Yeah I am an amateur, so I am ALWAYS willing to learn a better way.
Thanks very much!
I would recommend using a transparent button instead of a label.
The main reason is that you can set the mouse cursor to become a small hand when you hover over the button, so it gives back information to the user that this can be clicked.
With a label, the user cannot make the difference between a normal label and one that can be clicked since there is no visual cue.
To create a button that resemble a label:
Add the button to the form
In the properties for the button, set the following:
Format > Back-Style: Transparent
Other > Cursor on Hover: Hyperlink Hand
Other > Name: btAutoFill (or whatever name you want)
If you want the button to resemble a link a bit more, you can change it's caption's format, making it blue and underlined if you wish.
Now if you view the form, you will see that the mouse cursor will change when you move over the 'button label'.
To automatically fill-in other controls when you click your button, add the code to handle its OnClick event (in the button's properties, under Events > On Click, choose [Event Procedure]):
Public Sub btAutoFill_Click()
myTextBox = "NVOWEFDJHF"
End Sub
Quick air code here...
Private Sub MyLabel_OnClick()
Me.MyTextBox = "NVOWEGDJHF"
End Sub
Don't forget your error handling.
You're making this as difficult as possible by using an approach that is not Access-native. The simplest way to make the labels "clickable" is to put a transparent command button over them. But that means the MouseMove events will go to the command button, so you'll have to have its events do the MouseOver actions.