What's the difference between "print" and "printo" verbs when starting a process? - windows

I suspect this may apply to multiple programming languages, but in this context I am referring to .NET.
When I use System.Diagnostics.Process.Start, I can include, as an argument, a System.Diagnostics.ProcessStartInfo object. One of the properties of ProcessStartInfo class is Verb (type of string). There is also a string[] property of Verbs which seems to contain the list of permitted values for Verb.
I notice that within the Verbs array there is a value for "Print" and a value for "PrintTo". What's the difference between the two? I tested both and they both seem to cause the file to print to my default printer.

According to this MSDN article, PrintTo is basically present to support drag-and-drop operations for printing (dragging a document over a printer icon, for example). It sounds like it's probably not meant to be used by your code.

The printto verb is normally used when the user drags a file and drops it on a printer shortcut. You need to supply at least two arguments, the first one is the file you want to get printed, the second one is the printer name. Registry entries on my machine use additional arguments but it is quite unclear to me what they may be.

Related

Is there some standard for handling sets of ranges of numbers?

When you open the print dialog of an editor, you typically get a field for specifying which pages you want to print - which can be multiple ranges, e.g.: "5,11,31-33"
Now, there are other scenarios in which this kind of input from a user is relevant - especially in configuration files for sequential or iterative processes where you want to qualify which iterations or elements a certain action or feature should apply to.
However, I'm not aware of a name for this kind of strings; nor of an accepted standard format/convention for them (i.e. can you add spaces? Can you use semicolons instead of commas? Must the ranges be sorted? Are overlaps allowed and are they maintained or discarded? Can ranges use ".." instead of "-"? Can you range down instead of up? etc.).
Is there some such convention or such standard?
My motivation is double: I need to parse such ranges in a piece of code I'm looking at, any I want both to do it correctly (or rather per-convention), and secondly to go look for parsing functionality in existing libraries. Right now I don't even have a name to go on.

How do you find the correct verb names to use with FolderItem.InvokeVerb?

How does one find the exact verbs to be used with the Windows API function FolderItem.InvokeVerb? The documentation says, "It must be one of the values returned by the item's FolderItemVerb.Name property." However, this does not seem to be true.
Using a folder as an example, if you run this on Windows 10 (using PowerShell):
$Shell = New-Object -ComObject 'Shell.Application'
$Shell.NameSpace('C:\Windows').Self.Verbs()
you will get a list that looks like this:
Application Parent Name
----------- ------ ----
&Open
Pin to Quick access
Scan with Microsoft Defender...
... and so on.
Those Names are what you get in an Explorer context menu, but they do not work with InvokeVerb. For some of them, such as &Open, all you have to do is remove the &. For others, such as Pin to Quick access, the actual verb that works is altogether different (pintohome). How can one reliably find these "actual" verbs for an arbitrary item?
I have found that the verbs that do work with InvokeVerb correspond to the sub-keys that you can find in the Registry under HKCR\<class name>\shell. However, even knowing that does not make things simple. I have found some verbs before by searching HKCR for the string returned by FolderItemVerb.Name, but that doesn't work if the string is localized. If you happen to know the name of the class, you could look there directly. (Using the folder example, pintohome is one of the keys under HKCR\Folder\shell.) However, when it is localized, there is nothing there that directly indicates this is the verb you are looking for, so you have to try it to find out. And, if you are inside some special shell folder or namespace extension, you might not know what class name(s) to even go looking for.

What is the argument type and return type for web elements in qtp?

I keep seeing code like this:
.WebButton("locator1", "locator2", "locator3")
What is the type of arguments in WebButton, WebElement, WebEdit etc ? I tried passing an array to .WebButton. So, qtp told me its not the correct type. Is there an alternate way to pass multiple locators ?
Also, what is the return type of .WebButton, .WebElement etc. ?
The "arguments" which you are talking about are the set of properties which are needed by QTP/UFT to identify that particular object(WebElement, WebEdit etc.) uniquely so that one can perform actions on them.
Also, this is not some sort of a function that is going to return you any value.
If you are not sure about what properties you need to mention in those brackets, an easier way would be to add that object to the Object Repository and drag that object from OR to your script. After that you can perform any action on those objects.
If you do not want to use OR, then you need to make use of, what we call, Descriptive Programming(DP) wherein you have to mention the object property names and their values "explicitly" in the script.
Remember that the sole purpose of mentioning these properties is to help QTP identify the objects in your application so that you can perform actions on them(like click, set etc.)
Here are a few links which can help you:
http://www.learnqtp.com/descriptive-programming-simplified/
http://www.guru99.com/quick-test-professional-qtp-tutorial-6.html
http://www.guru99.com/quick-test-professional-qtp-tutorial-32.html
EDIT 2 - for answering your question in the comment:
.WebButton("Locator1","Locator2","Locator3") means .webButton("property1:=value1","property2:=value2","property3:=value3")
Now, I could have only mentioned property-value pair1(which you are referring to as "Locator1") only If it alone was sufficient for identifying that webbutton. If only 1 property-value pair cannot help UFT in UNIQUELY recognizing the webbutton, then I have to provide another property-value pair until I have provided enough of them so that QTP recognizes that webbutton uniquely. Since, I have provided multiple property-value pairs(or locators), they have to be separated by commas. If there was only one property-value pair, no comma is needed. All this explanation only applies to the case when we are using Descriptive Programming. If we are not using Descriptive programming, then in that case the objects and their properties&values are stored in the Object Repository and you just have to mention their logical names(say Button1 as stored in OR) in the script like:
.webButon("Button1")
To understand more, you need to do some more research on "How object Identification works in UFT/QTP"

How does Windows interpret multiple VersionInfo Resources?

I am currently studying the VersionInfo Resource(s) for Windows.
It is kind of confusing that you can have multiple VS_VERSIONINFO/VS_FIXEDFILEINFO structures within a VS_VERSION_INFO Resource.
As far as I get it, you can have multiple RT_VERSION->VS_VERSION_INFO Resources with different language ids. (Just as shown as in the picture)
These 2 language ids (0 and 1031) have actually 2 different VS_VERSIONINFO/VS_FIXEDFILEINFO in each.
0 is a neutral language and seems to be prioritized than your actual local language id (which is 1031).
To me this seems to be kind of a mess and confusing.
How is it possible to have multiple VS_VERSIONINFO structures within a VS_VERSION_INFO resource and what is the point? How does Windows interpret multiple Resources,Structures?
And how is it possible to get only one piece of buffer when you call GetFileVersionInfo?
It all makes little sense to me and I can't find much documentation about it.
You have to make a difference between the textual infos, and the bare VS_FIXEDFILEINFO block. The first block exist only once. The text Information is language dependent.
"Windows" does not prefers a specific one ;) What the explorer does is a different thing. It just shows the resource information. But in fact this is just the string information and not the information from the fixed version info.
When you call GetFileVersionInfo you get all language blocks! VerQueryValue is used to access he separate blocks.
The installer and other routines inside windows only use the VS_FIXEDFILEINFO block. They don't care about any text blocks. And this block only exists once.
I assume that the explorer just shows the first text block and also doesn't prefer a specific one. Just use a text editor and exchange the blocks in the resource file. But maybe the resource compiler reorders them.
To access the separate parts:
- VerQueryValue with "\" gives you the fixed version info block VS_FIXEDFILEINFO
- VerQueryValue with "\VarFileInfo\Translation" gives you a list of translations
- with "\StringFileInfo\langId_charset\keyname" you get the specific string parts
You find this information in the MSDN

What are the best practices for building multi-lingual applications on win32?

I have to build a GUI application on Windows Mobile, and would like it to be able user to choose the language she wants, or application to choose the language automatically. I consider using multiple dlls containing just required resources.
1) What is the preferred (default?) way to get the application choose the proper resource language automatically, without user intervention? Any samples?
2) What are my options to allow user / application control what language should it display?
3) If possible, how do I create a dll that would contain multiple language resources and then dynamically choose the language?
For #1, you can use the GetSystemDefaultLangID function to get the language identifier for the machine.
For #2, you could list languages you support and when the user selects one, write the selection into a text file or registry (is there a registry on Windows Mobile?). On startup, use the function in #1 only if there is no selection in the file or registry.
For #3, the way we do it is to have one resource DLL per language, each of which contains the same resource IDs. Once you figure out the language, load the DLL for that language and the rest just works.
Re 1: The previous GetSystemDefuaultLangID suggestion is a good one.
Re 2: You can ask as a first step in your installation. Or you can package different installers for each language.
Re 3:
In theory the DLL method mentioned above sounds great, however in practice it didn't work very well at all for me personally.
A better method is to surround all of the strings in your program with either: Localize or NoLocalize.
MessageBox(Localize("Hello"), Localize("Title"), MB_OK);
RegOpenKey(NoLocalize("\\SOFTWARE\\RegKey"), ...);
Localize is just a function that converts your english text to a the selected language. NoLocalize does nothing.
You want to surround your strings with these values though because you can build a couple of useful scripts in your scripting language of choice.
1) A script that searches for all the Localize(" prefixes and outputs a .ini file with english=otherlangauge name value pairs. If the output .ini file already contains a mapping you don't add it again. You never re-create the ini file completely, your script just adds the missing ones each time you run your script.
2) A script that searches all the strings and makes sure they are surrounded by either Localize(" or NoLocalize(". If not it tells you which strings you still need to localize.
The reason #2 is important is because you need to make sure all of your strings are actually consciously marked as needing localization or not. Otherwise it is absolutely impossible to make sure you have proper localization.
The reason for #1 instead of loading from a DLL is because it takes no work to maintain this solution and you can add new strings that need to be translated on the fly.
You ship the ini files that are output with your program. You also give these ini files to your translators so they can convert the english=otherlanguage pairs. When they send it back to you, you simply replace your checked in .ini file with the one given by your translator. Running your script as mentioned in #1 will re-add any missing translations if any were done while the translator was translating.

Resources