I have an MS Access form that checks for certain records in a form timer event.
When it finds records it prints a report to the default Windows printer.
The problem is the Windows print status/progress window pops up (You know, the one that goes Printing page x of (document name)). And it, of course, has a cancel button.
But that progress window is interfering with normal form operations. I want to print in the background (silent printing?) without showing that progress window.
Any way to do that in the printer settings or from vba or other?
No, that's by design.
But you could move this timer form and the report to another database and run this minimized - your current application could open this automatically when launched.
I am looking to write a small application that will reside as a button on the Task Bar in Windows (it's fine if it is only compatible with Win7+), but I cannot figure out where to start to to put a widget onto the task bar itself.
See this attached image, taken from an HP laptop where the custom support center is overlayed on the task bar:
Note, this is not a standard application icon that exists in the system tray. Nor is it your standard taskbar button, i.e. a pinned shortcut. It is a custom program of some sort that registers this item on the task bar. I've seen similar things on other machines where the battery indicator is there, and has the current charge (before Windows 7 added an icon for that).
I am looking to position an interactive element at the start of the task bar like this one (only in a different position, more left, next to the start button). I have been looking high and low for documentation to help me get started with this element, and I cannot find anything. Can anyone provide a hint on how to get started?
I can write in C#, C++, whatever, so just a pointer to the right spot would be great. Thank you.
I'm a Mac user and a Windows user (and once upon a time I used to be an Amiga user). I much prefer the menu-bar-at-the-top-of-the-screen approach that Mac (and Amiga) take (/took), and I'd like to write something for Windows that can provide this functionality (and work with existing applications).
I know this is a little ambitious, especially as it's just an itch-to-scratch type of a project and, thanks to a growing family, I have virtually zero free time. I looked in to this a few years a go and concluded that it was very difficult, but that was before StackOverflow ;)
I presume that I would need to do something like this to achieve the desired outcome:
Create application that will be the custom menu bar that sits on top of all other windows. The custom menus would have to provide all functionality to replace the standard Win32 in-window menus. That's OK, it's just an application that behaves like a menu bar.
It would continuously enumerate windows to find windows that are being created/destroyed. It would enumerate the child windows collection to find the menu bar.
It would build a menu that represents the menu options in the window.
It would hide the menu bar in the window and move all direct child windows up by a corresponding pixel amount. It would shorten the window height too.
It would capture all messages that an application sends to its menu, to adjust the custom menu accordingly.
It would constantly poll for the currently active window, so it can switch menus when necessary.
When a menu hit occurs, it would post a message to the window using the hwnd of the real menu child control.
That's it! Easy, eh? No, probably not.
I would really appreciate any advice from Win32 gurus about where to start, ideas, pitfalls, thoughts on if it's even possible. I'm not a Win32 C++ programmer by day, but I've done a bit in my time and I don't mind digging my way through the MSDN platform SDK docs...
(I also have another idea, to create a taskbar for each screen in a multi-monitor setup and show the active windows for the desktop -- but I think I can do that in managed code and save myself a lot of work).
The real difference between the Mac menu accross the top, and the Windows approach, is not just in the menu :- Its how the menu is used to crack open MDI apps.
In windows, MDI applications - like dev studio and office - have all their document windows hosted inside an application frame window. On the Mac, there are no per-application frame windows, all document windows share the desktop with all other document windows from other applications.
Lacking the ability to do a deep rework of traditional MDI apps to get their document windows out and onto the desktop, an attempt, however noble, to get a desktop menu, seems doomed to be a novelty with no real use or utility.
I am, all things considered, rather depressed by the current state of window managers on both Mac and Windows (and Linux): Things like tabbed paged in browsers are really acts of desperation by application developers who have not been given such things as part of the standard window manager - which is where I believe tabs really belong. Why should notepad++ have a set of tabs, and chrome, and firefox, and internet explorer (yes, I have been known to run all 4), along with dev studios docking view, various paint programs.
Its just a mess of different interpretations of what a modern multi document interface should look like.
The menu bar on a typical window is part of the non-client area of the window. It's drawn when the WndProc gets a WM_NCPAINT message and passes it on to DefWindowProc, which is part of User32.dll - the core window manager code.
Other things that are drawn in the same message? The caption, the window borders, the min/max/close boxes. These are all drawn while processing a single message. So in order to hide the menu for an application, you will have to take over handling of this message, which means changing the behavior of user32.dll. Hiding the menu is going to mean that you become responsible for drawing all of the non-client area.
And the appearance of all of these elements - The caption, the borders, etc. changes with every major version of Windows. So you have to chase that as well.
That's just one of about a dozen insurmountable problems with this idea. Even Microsoft probably couldn't pull this off and they have access to the source code of user32.dll!
It would be a far less difficult job to echo the menu for each application at the top of the screen, and even that is a nearly impossible job. When the menu pops there is lots of interaction with the application during which the menu can be (and often is) changed. It is very common for applications to change the state of menu items just before they are drawn. So you will have to replicate not only the appearance of the menus, but their entire message flow interaction with the application.
What you are trying to do is about a dozen impossible jobs all at once, If you try it, you will probably learn a lot, but you will never get it to work.
This question is more academic than practical and doesn't involve any one specific language. For the sake of discussion, we'll use Win32 API.
What is the most appropriate way to create a window with the following behavior goals:
Z-Order is lower than every other window except the desktop surface.
Cannot be made to appear on a higher z-order than other windows through mouse or keyboard clicks.
Assumption may be made that the window is borderless.
There are two basic approaches here :-
make your window the 'child' of the desktop.
make your window simply refuse to accept focus or activation :-
The wonder of the windows window manager is that there isn't one. Rather, there is an appearance of a window manager as a result of the emergent behavior of all the windows in the system - namely how they react to messages - which in 99% of cases is handeld by DefWindowProc.
Which means that you can subvert a lot of normal window manager type behaviour by handling messages before DefWindowProc. If you create a window, and position it using the relevent flags at the bottom of the z-order with SetWindowPos, and then handle messages like WM_WINDOWPOSCHANGING, you can ensure that your window never receives activation or focus and always - even when other apps call SetWindowPos - always has the z-bottom flag set.
both approaches are problematic as its very difficult to find out what the desktop window is. GetDesktopWindow returns a handle to a window that is only ever visible if explorer crashes. The rest of the time, the visible desktop is a window created by explorer - ultimately a syslistview control. Spy++ + Findwindow will get you a handle to the window you want to be above.
I've seen a few Windows 7 applications popping up around the web that take advantage of the new task bar functionality. However, some of these applications are treating the task bar like the notification area. There is no foreground window. All interaction is done through the task bar button (with overlays, progress bars, jump lists, etc).
Personally, I like the new task bar more than the notification area because I have the ability to use larger icons and give the user a very familiar user interface with a rich experience. But I also feel like applications like those described above should be kept in the notification area.
What do you think about applications that use the Windows 7 task bar as the "new notification area"? Should it be avoided?
Microsoft is doing its best to discourage use of the 'notification area', frequently referred to as the 'System Tray'. Instead they encourage more detailed and interactive application icons. For example, the progress bar that's visible on the explorer icon when you're performing file operations in the explorer.
Read the windows user experience interaction guidelines for more details on the new recommended functionality.