I want to figure out what this is called on visual studio.
I am trying to develop a small program that shows different lists depending on the time. This list references a database
I am trying to change the list that appears when i right click the program on the background task. Similar to this example where i right click outlook's background app and receive a list
This (system tray icon and its context menu) dates back at least two decades, and has been extensively covered in Windows programming books a long while ago.
You can still find legacy materials like NotifyIcon in Windows Forms,
https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/notifyicon-component-windows-forms?view=netframeworkdesktop-4.8
If you are going to write your own program, make sure you choose a proper UI framework first (Windows Forms is too old but still supporteD), and then use the equivalent control to achieve the same functionalities.
Related
Is it possible to for an app to respond to Expose on MacOS such that it can choose what gets displayed?
I often use Expose to switch windows. The problem is if the windows look similar then it's harder to know at a glance which one I want.
Trying to switch to one of the 4 Visual Studio Code windows or one of the 4 terminal windows is not as easy as it could be if each window showed more info, for example the document name.
I can hover the mouse over each window but that's not "at a glance" so what I'd like to do is, if and only if Expose appears, choose what Expose shows for my app.
One solution I thought of is to change the display if my app's window does not have the focus. Unfortunately that's not a solution. Often I have windows side by side so I can see both windows. If I changed the display of the unfocused window that would make side by side unusable.
Does MacOS provide an API for responding to expose? Note: I'm asking a programming question. If I was to want to add this feature to Visual Studio Code or ITerm2 or my own app what is the MacOS level event I trigger on? I've never seen an app change its representation in expose so I'm guessing there is no way to do it.
I would like to know is there a way to drive an existing windows application? I want to execute operations in an application like filling out text fields in a form, hitting next and submit buttons, etc. Basically what a user would do, I wanted to automate those operations. What would be the best way to achieve this?
Thanks
Mukul
It is possible (with limitations and quirks), if that particular Windows application uses native windows (so-called) controls (UI elements). Qt, for example, paints UI elements "by hand", while MFC applications uses Win API UI native (and expanded) elements. So, it depends.
You can explore application and it's UI elements using Spy++ tool inside Visual Studio (there are free alternatives available). Using these tools, you can look up target window class name, ID and other attributes that would help you to find and identify elements of interest using Windows API functions.
One can use EnumDesktopWindows, FindWindowEx, FindWindow, and others, to find window and it's inner control of your interest. Then, using SendMessage you can send various messages to set focus, emulate mouse clicks, set text for Edit control, simulate button clicks, etc, etc.
You can write such a program using UI Automation, which allows a program to discover and use the GUI of another application. It's how accessibility tools like screen readers interact with your applications.
I need to create a Win32 application. I am using visual studio. I really like designing my application in Windows Form, which allows graphically designing my window.
However, I cannot use Windows Form (only). I have to use Win32 applicaition. Now, when I create Win32 application, I cannot figure to graphically design my window.
Is there a way to incorporate Windows Form in Win32 application? Or graphically design Win32 window?
(If there is a way to design Win32 applications GUI graphically and it's just me who could not figure it, I would appreciate resources or methods to do so.)
In a Win32 application, you can include a dialog resource that contains controls and layout information for a particular window. Visual Studio includes a graphical dialog resource editor, as do many other Win32 resource editing applications. This will be somewhat similar to what you're used to with the WinForms designer, albeit with a few limitations. Win32 is a much older technology than WinForms and wasn't really designed with RAD (rapid application development) principles in mind.
When you create a new Win32 project based on the template in Visual Studio, you already get one dialog resource created for you: the About box. If you double-click on your "ProjectName.rc" file in the Solution Explorer, then expand the "Dialog" resources folder, you'll see it. Double-clicking on it will bring up the Dialog Editor for this dialog window. You can add controls using the familiar Toolbox window, and customize them using the familiar Properties window.
You will still need to write code that displays the dialog window, of course. There are two basic methods of doing so:
The DialogBox function will display the dialog modally, which means that the user has to close the dialog before they can interact with the rest of your application. Inconvenient for the user, but rather convenient for the programmer because Windows runs the dialog's message loop for you.
The CreateDialog function will display a normal (non-modal) dialog, but requires that you write your own message loop for the dialog window, just as you would for a normal non-dialog window.
You could conceivably design all of the windows for your application this way, by adding separate dialog resources for each of them, but it is not necessarily a good idea. Part of learning a new UI framework is learning how to use that framework the way it is meant to be used. Creating controls and setting their properties through code at runtime is not really that difficult, and it is a lot more powerful than limiting yourself to a fixed layout. (In fact, even when you have a dialog resource with a fixed layout, you'll often want to write similar code to allow customizing those controls at runtime.)
How can a Delphi XE application show a popup menu inside another application's window? The idea is for a helper-type app, running in the background. On a registered hotkey the application needs to display a popup menu near the text caret or mouse cursor.
Applications that do that are common, here's a menu created by AutoHotkey and displayed in a text editor:
I guess what I'm asking is: how can I display a popup menu at an arbitrary screen location, without it being attached to a Delphi control?
Create a TPopupMenu with the appropriate menu items. When you need to show it simply call Popup passing the top left position in screen coordinates.
PopupMenu1.Popup(X, Y);
#DavidHeffernan answered your question, but you might not have asked the right question.
Let's take the example you gave: the user is running some arbirary application, and you want to be able to detect a hotkey, display a menu, and then take some action based on the menu item chosen (and maybe even the user's context, such as the word under the cursor). This is more complicated than simply displaying a menu at arbitrary screen coordinates.
My recommendation is to use AutoHotKey instead of trying to replicate this in some other programming language. In case you're not aware of this, it is possible for your code to run AutoHotKey scripts. IIRC, you can compile AHK scripts, so you wouldn't need to install AHK, just the compiled scripts. AHK may not be the most elegant of solutions, but it has depth and maturity.
If this is not possible, then I suggest you research Windows Hooks and DLL Injection. Unless you can find some preexisting code or framework, this will entail quite a bit of work.
The reason for this complexity? To augment another program smoothly (without running into problems with focus, etc.) you want to have your code run as part of that other program. The mechanics of this can be done via DLL injection. However, that's only the first step. Once your code is running in the right context, then your code has to inter-operate with the "host" program. This can be tricky (it helps if you have deep experience with Windows messaging and the Windows API). If you want this to work smoothly with any arbitrary program, it gets even harder.
I have a confusion that MSWord is a MDI or SDI application. Looking at the Application, I do believe that it is a SDI application but there are people who strongly "believe" that its an example of MDI. After using the Taskmanager in windows, the Applications tab list all all the instances of the Documents currently opened. However there is only one process in the Processes tab.
Since all the documents have same process, it make me feel its an MDI. But at the same time, the Applications tab lists all the documents opened make methink its an SDI. What do you people think about this? Please give your valuable and detailed answers.
If you uncheck Show all documents in the taskbar in Options, Word is a classical MDI application (even Word 2010).
If you leave it checked, it's an SDI application with multiple root windows.
According to Microsoft, it is an MDI application: http://msdn.microsoft.com/en-us/library/aa263481(v=vs.60).aspx
Depending on your settings and version, it could be MDI or SDI. It is MDI in older versions and if you use the "Show all documents in taskbar" option; otherwise, it is SDI.
Honestly, I didn't realize this part myself, until I tested:
After using the Taskmanager in windows, the Applications tab list all all the instances of the Documents currently opened. However there is only one process in the Processes tab.
Thank you and +1 on the post. On exploring further, I found something that might shed light further. I am using 2007, but I guess it would apply for 2010 as well. I clicked on the Control Menu (the small menu that pops up when you click on the Icon on the top left corner - used to be called Control Menu, before Microsoft decided to redraw its interface). You would find a "Word Options" button. Click on it, in the dialog that pops up after that, go to "Advanced" tab. Scroll down to the "Display" section. Locate the "Show all windows in the Taskbar" check box, I guess it will be checked. Uncheck it. You would see that there are no multiple windows (corresponding to each document) anymore. Also, in Task Manager, you will see only one instance even in the Applications Tab.
With this, I strongly believe Word is still an MDI. Oh by the way, if you want to see every document opened after you change these "Advanced" options, you might want to go to View menu and and chose "View side by side" option.
I came across some more info regarding this from Chris Ryan which I am sharing here:
It depends on what you mean by MDI.
MS-Word does have multiple documents and an interface but it does not fit the classic definition of an MDI application because it does not use an MDICLIENT window class to manage the child frames.
For an example of an MDICLIENT, see:
ftp://ftp.charlespetzold.com/ProgWin5/Chap19/MDIDemo/MDIDemo.c .
ftp://ftp.charlespetzold.com/ProgWin5/Chap19/MDIDemo/Release/MDIDemo.exe
Even the older versions of Word and Excel that had the child windows inside the main frame, were technically not MDI. They looked like it but they did not use MDICLIENT. MS used a proprietary windowing library called Software Dialog Manager. SDM was used so a common application code base could be used on multiple platforms: Windows, OS/2, & Mac. All they had to do was recompile for that platform and link a platform specific SDM library.
This link talks a little about SDM but does not mention MDICLIENT
http://msdn.microsoft.com/en-us/library/windows/desktop/dd317997(v=vs.85).aspx