i want to write an application, which reads under windows xp the quick launch items in the order like they are located in the taskbar,
and sets hotkeys for each of these item.
windows + 1 should start the first application
windows + 2 the second, etc.
(like in windows 7)
all of these items are found i a folder, but if i read the items of this folder, i dont get the right order of these items.
i found two solutions the get the right order - first:
in the registry an entry is found, where its saved how they are located, but not in plain text. i dont know how to read this, and cant reverse engine it.
the second:
read via winapi the items tooltip from the taskbar, so i can (if there are not items with the same name) search via the name in the quick launch folder.
the quick launch bar is just a listview (syslistview32).
via sendmessage i got it work to count the items, and start one (faking a click on this item), but how the hell can i read the tooltip?
i have googled a lot, tried everything, but i didnt get it run.
i hope you have any snippets for me, to solve this problem.
cheers
Determining the order of the items in the Quick Launch toolbar programmatically is going to be inherently fragile. There's not an API exposed for this, which means that it's subject to change in future versions of Windows, breaking your code that relied on assumptions about undocumented implementation details.
However, this is less of a problem in this specific case than it normally would be, since the Quick Launch toolbar doesn't exist anymore (or, at least, no one uses it anymore). The last version of Windows that used the Quick Launch toolbar was Vista, so if you make sure that your code is compatible with Vista and earlier, you should be fine. It won't work with newer versions anyway.
The positions of items in the Quick Launch toolbar is stored in the Registry in the following key:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Streams\Desktop
You can extract the information from there, parse and interpret it, and then use it as you like. As you mention, this information isn't stored in plain text form because that would be very slow for the shell to load and parse itself. Since this is undocumented and not designed to be used by clients, they had no particular benefit in making it user (or developer) friendly. All that matters is what's most efficient for the shell, and storing the binary information from its internal structures is the obvious choice.
You will need to reverse engineer this in order for it to be useful to you. The way I'd go about it is probably by setting up a test environment with a couple of items in the Quick Launch bar in a particular order, exporting the information from the Registry, moving one of the items around, exporting the updated information from the Registry, and comparing the two exported Registry files to see what changed. Rinse and repeat as many times as necessary to deduce the pattern. (Really makes you wonder why so many developers actually do take the time to reverse-engineer undocumented aspects of Windows, doesn't it?)
The other option would be to use Spy++ to investigate the windows that implement the taskbar and its Quick Launch toolbar. I don't have a pre-Windows 7 system around, but it sounds like from the question that you've already done this and determined that the Quick Launch toolbar is implemented using a standard ListView. If you know the name of that window (and the names of its ancestor windows), you can walk through those windows to obtain a handle to the window you're interested in. And then you can determine the order of the items in the window as if it were a standard ListView in your own application.
The documentation for ListView controls is here; that should get you started in the right direction. You can get the text of one of the subitems by sending the LVM_GETITEMTEXT message.
This is probably the easier way of doing it. The same caveats apply--there is nothing keeping future versions of Windows from changing the names of those windows or the way that the taskbar is implemented, but since the only versions of Windows that have a Quick Launch toolbar have already been released (and therefore aren't likely to change), this may not be a big problem.
Then again, with the fact of the Quick Launch toolbar's obsolescence in mind, I struggle to comprehend why this endeavor is even worthy of investing developer time.
Also, even once you get this program all written and installed, consider what happens when the user adds a new item to the Quick Launch toolbar or re-arranges the existing items. How is your utility going to know that and adjust the keyboard shortcuts accordingly? What if an installer adds/removes an item from the Quick Launch toolbar?
Related
I'm using the built in spell checker in WPF. It was working just fine until I had users start upgrading to windows 10... I think the issue is that it's being used for a lot of small text boxes. My application presents a grid (Telerik's TreeListView) with text boxes for one of the columns which i want spell checked. I need to be able to provide a custom dictionary to the spell checker; the only way I was able to do this was to subscribe to the textbox loaded event and add the paths in as follows:
TextBox tb = sender as TextBox;
tb.ContextMenu = ctx_Spell;
IList dcts = SpellCheck.GetCustomDictionaries(tb);
dictsList.Add(dcts);
if (KMApplication.Settings.UserDictionary != null)
{ dcts.Add(KMApplication.Settings.UserDictionary); }
foreach (Uri dct in KMApplication.Settings.RevitDictonaries)
{ dcts.Add(dct); }
Granted this calls the add for each and every text box which seems terribly wasteful, but it seemed to be working just fine with little noticeable lag and only on load up. However now on Windows 10 it seems to be a ridiculous lag. On my Windows 8.1 machine I load up a file with a few thousand rows and it appears in about 3 or 4 seconds; on my Windows 10 box, it appears in about 10-15 minutes. If I comment out the custom dictionaries portion of the above code it's back to about 3-4 seconds on either machine.
Does anyone know a better way to do this? Or if there is some way around it in Win10?
We have experienced a similar issue and saw improved performance by avoiding re-registering custom dictionaries on every TextBox control during load.
Unfortunately, we hit another issue with the way custom dictionaries are handled which can also result in very long loading times if you have even a small number of TextBox controls.
When a WPF application registers a custom dictionary in .NET 4.6.1 on Windows 8.1/10, a temporary dictionary file is created in %localappdata%\Temp and this is registered in the multistring value _GLOBAL_ in the registry key "Computer\HKEY_CURRENT_USER\Software\Microsoft\Spelling\Dictionaries".
If the _GLOBAL_ value ends up referencing a dictionary file which does not exist, the application starts to exhibit very slow loading whenever a control with spell check enabled is initialized.
This can happen by using the "Stop debugging" button in Visual Studio and then running the Disk Clean-up or CCleaner after enough time has passed for these to delete the temp dictionary files.
We managed to fix this by clearing the _GLOBAL_ value of any links to dictionary files which did not exist. The our application began to work as expected.
We raised the following connect bug:
https://connect.microsoft.com/VisualStudio/feedback/details/2153484
Starting .NET 4.6.1 (in Win8.1 & Win10), WPF uses ISpellChecker interface exposed by the OS to implement its SpellChecker, and the performance characteristics could be somewhat different indeed.
Notably, ISpellChecker's custom dictionary registrar acts globally - it no longer acts as a per-control registration. (See KB article link below). As a result, registering the same set of dictionaries over and over for each control is wasteful and can potentially degrade your performance. Besides, the OS will just start ignoring your dictionaries when it reaches an internal limit.
Just register the dictionaries once, or use the alternative registration mechanism outlined at http://blogs.msdn.com/b/wpf/archive/2015/10/29/wpf-in-net-4-6-1.aspx and place the files under %appdata%\microsoft\spelling\.
If you need to run the same application on Win7/Win8 as well as Win8.1/Win10, you may need to detect the OS and branch your dictionary registration strategy.
In general, typical uses of custom dictionaries should continue working as usual - with little difference between .NET 4.6.1 vs previous releases.
Also see https://support.microsoft.com/en-us/kb/3088234 for additional information.
Firstly, I want to mention that I know that the post is already a few years old but I think that my answer might help someone out there who has the same problem but where the presented solutions didn't work (like myself).
What fixed it for me was to add the following code to App.config:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.DoNotAugmentWordBreakingUsingSpeller=true"/>
</runtime>
Alternatively you can also insert the following code after your InitializeComponent() call:
AppContext.SetSwitch(#"Switch.System.Windows.Controls.DoNotAugmentWordBreakingUsingSpeller", true);
Source 1 (XAML solution)
Source 2 (C# solution)
I would like to know if there is any way to extend the task manager in a language like C# preferably but i'm also ok with C++, or anything else that works.
I would like to add some new features like, search, kill all processes with the same name, and what ever else comes to mind, but i have no idea were to start.
Note: I don't want to replace it or rewrite it from scratch, just add some new features.
I also found this link Is it possible to add functionality to Vista/7 taskmgr.exe? but it's for VIsta/7 i'm just hoping something change in 8, considering that it was completely redesigned.
Thank you
If i am correct, what you want to know is if there is a way to extend TaskManager via a plugin based approach( like Office/Ie/Outlook plugins).
The answer is no.
I however have a different approach which may help you do what you want but would be a lot more work.
What i suggest is Com interop based injection and override.
using Spy++ you can see what are the window classes/properties of the TaskManager window. Then you would need to write a program which works minimized(system tray?!) and watches for some identifying window/class name to pop up in the messages system. Windows messages can be intercepted and hooked. http://www.codeproject.com/Articles/33459/Spying-Window-Messages-from-the-Inside may be of some help.
Once you get your window handle. you will probably need to find the tabs control group. and inject a new tab element. Post which you can put anything which you deem into the tab element.
This is speculative, and involves the assumption that all the new changes you want to add would end up in a new tab.
I hope this helps you in some way.
PS: The answer is not totally speculative though. For some internal use at my workplace, I had made a prototype which would do something similar to outlook and override some default functionality which wasn't exposed by the Add in framework per se. Beware that this would require lots of testing and was somewhat unreliable/unstable
As is well-known, WPF still doesn't supply a folder selection dialog (unless WPF4 has one that I've missed). In the meantime, I am using System.Windows.Forms.FolderBrowserDialog.
Unfortunately, this dialog only has a folder tree, OK, Cancel, and an optional "Make New Folder" button. The usability is poor. Particularly, it is terrible when trying to select a network folder. The only way to select the folder is to expand the "Network" base.. which on many corporate systems/networks, will begin a long delay and ultimately yield an unacceptably long list.
I would like a text entry field which would allow the user to start navigation at a particular location.. such as a particular computer/folder.. such as is possible in the file browse dialog.
Has anyone done such a thing? Is this a way to extend the standard System.Windows.Forms.FolderBrowserDialog, or will I have to create my own?
Thanks.
Vista Bridge provides managed wrappers for the new Vista dialogs with fallback support when running on older OS. These file dialogs are preferrable to either the stock WPF or WinForms ones.
The Windows API Code Pack provides managed wrappers for Windows 7 features.
I think you should create your own, no default folder dialog implement something like this. If I'm not wrong, java too doesn't allow such possibility.
I normally create the "open folder dialog" button near a textbox where the path can be written manually (when the folder dialog button is closed with ok button simply fill that textbox), that's the easiest way.
Your type of dialog should be created, on the good side you can at least sell it because it looks nice and helpful. Or maybe you can find something similar on the web (previous payment by the way).
Another thing, all folders dialog are very slow, at least on windows XP, maybe is "impossible" to reduce those delays, you should do some searches to avoid this problem (multi-threaded dialog which gather information while giving possibility to start navigating through directory tree is the only thing i can think about).
Hope this will be helpful
EDIT:
Maybe this has some sort of utility,
http://www.ssware.com/fldrview.htm
it looks cool but doesn't have all features you want, I think it doesn't exist as you hope
You wrap native code and use the SHBrowseForFolder function:
http://msdn.microsoft.com/en-us/library/bb762115(v=vs.85).aspx
Or starting with Vista you could use create a COM object with the id "CLSID_FileOpenDialog" (native code, too):
http://msdn.microsoft.com/en-us/library/bb776913(VS.85).aspx
Both of those provide a text input area where you can type in UNC paths.
I'm working on an existing project that has a text import tool written in C#. It essentially shuffles to the last window that had focus, copies the text, switches back and pastes the text in the textbox. To do this it essentially issues keyboard commands so: Alt + Tab, Ctrl + A, Ctrl + C, Alt + Tab and then finally get the text from the clipboard and add it to the textbox.
Currently, it works terrific on XP. It doesn't, however, work on Vista/Win 7. It will switch to the new window and that appears to be it but when I go back to the C# it has added whatever was previously in the clipboard (not successfully copying the new text). My guess is that there's some problem telling another window to use the keyboard keys (Select All and Copy).
I have done some moderate searching online and haven't really found anything so I was hoping to see if anyone may have had a similar problem.
Assuming you're using SendKeys, you might want to look at this comment on the SendKeys MSDN page. If this is something introduced with Vista, it'd almost certainly affect Windows 7 as well, Id' think:
Note
The SendKeys class has been updated
for the .NET Framework 3.0 to enable
its use in applications that run on
Windows Vista. The enhanced security
of Windows Vista (known as User
Account Control or UAC) prevents the
previous implementation from working
as expected.
The SendKeys class is susceptible to
timing issues, which some developers
have had to work around. The updated
implementation is still susceptible to
timing issues, but is slightly faster
and may require changes to the
workarounds. The SendKeys class tries
to use the previous implementation
first, and if that fails, uses the new
implementation. As a result, the
SendKeys class may behave differently
on different operating systems.
Additionally, when the SendKeys class
uses the new implementation, the
SendWait method will not wait for
messages to be processed when they are
sent to another process.
If your application relies on
consistent behavior regardless of the
operating system, you can force the
SendKeys class to use the new
implementation by adding the following
application setting to your app.config
file.
To force the SendKeys class to use the
previous implementation, use the value
"JournalHook" instead.
http://msdn.microsoft.com/en-us/library/system.windows.forms.sendkeys.aspx
I want to create a program or use a program that will read the memory values out of another application. Does anyone know of an application/library that will do this?
The target app is this. I would like to read the exchange rate values from it.
I'm an experienced c# programmer, but have never worked with the Win32/user32 api which is what I'm assuming I'll have to deal with to pull this off.
Any help that gets me going in the right direction is greatly appreciated.
Update:
I managed to use Spy++ to get the window handle, so I'm sure I can get the values some how.
Have you looked into AutoIT or AutoHotKey?
Both of these open source options have well documented abilities to read text from application windows (and send keystrokes or mouseclicks to them).
AutoIT is very easy to use and well documented.
An example of reading text from a window would be:
$text = WinGetText("title of window", "")
MsgBox(0, "Text read was:", $text)
This can be compiled into an executable.
Typically an application creates controls in a dialog in a consistent manor, same ID, same order etc, so finding a control programatically is fairly simple. Using Spy++ find the control's ID and then you can search the windows created by the application for the desired control. Not being familiar with the app in question I cannot give specifics, but if Spy++ shows the value you desire, it is likely not difficult to obtain the value in your code.
What type of control is the value displayed in? You'll may be able to use GetDlgItemText to obtain the value once you have the parent window handle and control ID? To get the parent window try using EnumWindows.
It might be easier to scrape their data by automating a screenshot and then ocr process. If that's your goal.
Potentially relevant links:
get-a-screenshot-of-a-specific-application
ocr-with-the-tesseract-interface
May be this article helps - http://msdn.microsoft.com/en-us/magazine/cc163617.aspx, but I think it's not universal and for your task is better to get access directly to Forex API/Web-Service or try to catch needed data on network.
It is possible to screen-scrap things created with native windows controls; if that is the case, you should be able to see the controls using Spy++. But some times controls are implemented "by hand", and there is no way to screen-scrap them (e.g. some Java graphic toolkits play directly with the graphics, so everything day do is meaningless from the outside, or even some Office menus are implemented without using the menu control).
The Windows accessibility API is a possible way to screen-scrap the values; check if "Narrator", the screen reader that comes with windows, is able to read aloud your target application.