OpenWithView для Windows

Оценка:	1 2 3 4 5 0.00 /5 голосов — 0
Лицензия:	Бесплатная
Версия:	1.11 | Сообщить о новой версии
Обновлено:	17.05.2010
ОС:	Windows 10, 8, 7, XP
Интерфейс:	Английский
Разработчик:	Nir Sofer
Категория:	другое
Загрузок (сегодня/всего):	1 / 2 403 | Статистика
Размер:	36 Кб
СКАЧАТЬ

OpenWithView — небольшая утилита, которая отображает список всех доступных приложений в диалоговом окне «Открыть с помощью» и позволяет легко включать или отключать приложения в списке.

При отключении приложения оно больше не отображается в разделе «Другие программы» диалогового окна «Открыть с помощью». Данная утилита может быть полезна, если окно «Открыть с помощью» отображает слишком много неиспользуемых приложений.

Windows 7 USB/DVD Download Tool — отличный инструмент от компании Microsoft, с помощью которого можно легко.

MapKeyboard — небольшая бесплатная утилита с помощью которой можно легко переназначить или.

Распространяемый компонент Microsoft Visual C++ для Visual Studio 2015, 2017 и 2019, поскольку в VS 2015 и более.

Process Lasso — Небольшая утилита для операционных систем Windows, которая позволяет вручную или.

ExecutedProgramsList — простая небольшая портативная утилита, который отображает список программ и пакетных файлов, ранее выполненных и выполняемых в Вашей системе.

Бесплатная и простая в использовании утилита, с помощью которой можно буквально за пару.

Отзывы о программе OpenWithView

Павел про OpenWithView 1.11 [23-11-2020]

не видит некоторые программы
| | Ответить

Windows View

When you first open Spy++, Windows view displays a tree of all windows and controls in the system. The window handle and class name are shown. The current desktop window is at the top of the tree. All other windows are children of the desktop, and are listed according to the standard window hierarchy. Sibling windows appear in expansible lists indented below their parents.

The figure below shows a typical Spy++ Windows view with the top node expanded.

Spy++ Windows View

The current desktop window is at the top of the tree. All other windows are children of the desktop, and are listed according to the standard window hierarchy, with sibling windows ordered by Z-order. You can expand or collapse any parent node of the tree by clicking the + or — symbol next to the node.

When Windows view has the focus, you can use the Finder tool in the Window Search Dialog Box to display information from any window open on your system.

In This Section

How to: Use the Finder Tool Shows how this tool scans windows for properties or messages.

How to: Search for a Window in Windows View Explains how to find a specific window in Windows view.

How to: Display Window Properties m Procedures for opening the Window Properties dialog box.

Related Sections

Spy++ Views Explains the Spy++ tree views of windows, messages, processes, and threads.

Using Spy++ Introduces the Spy++ tool and explains how it can be used.

Find Window Dialog Box Used to view the properties or messages from a specific window.

Window Search Dialog Box Used to find the node for a specific window in Windows view.

Window Properties Dialog Box Used to display the properties of a window selected in Windows view.

Spy++ Reference Includes sections describing each Spy++ menu and dialog box.

Различия в поведении window.open в разных браузерах

При разработке одного сайта столкнулся с необходимостью проверить работу функции window.open в разных браузерах. Результаты решил оформить и выложить, глядишь кому понадобится, а кто и дополнит, что ещё лучше…

Для тестирования использовались: FireFox 3 beta 3, Netscape Navigator 9, Internet Explorer 6, Opera 9 и Konqueror 3.5 (тест Safari отдельно, в конце топика). При этом FireFox 3 тестировался в двух конфигурациях: по умолчанию и c TabMixPlus (с разрешением открывать popup-ы в новых окнах). Рабочая среда: KDE 3.5 на Debian.

1. Вызов без параметров

FireFox 3 (TMP)
Открыл полноразмерное окно, развернутое на весь экран (как и родительское).

FireFox 3
Открыл новую вкладку.

Navigator 9
Открыл полноразмерное окно, развернутое на весь экран (как и родительское).

Opera 9
Открыла новую вкладку.

IE 6
Открыл полноразмерное окно, развернутое на весь экран (как и родительское).

Konqueror
Открыл окно с размером по умолчанию (родительское окно было развёрнуто на весь рабочий стол).

2. Размеры окна

FireFox 3 (и с TMP и без)
Открыли окно с областью просмотра 640×480 пикселей. В окне отображается строка состояния и адресная строка (неактивная).
Само окно превышает заданный размер за счёт строки состояния, адресной строки, заголовка и границ окна. Размеры окна изменяемы.

Navigaror 9 и Konqueror
Открыли окно с областью просмотра 640×480 пикселей. Само окно превышает заданный размер за счёт заголовка и границ окна.
Размеры окна изменяемы.

Opera 9
Открыла окно с областью просмотра 640×480 пикселей. Само окно превышает заданный размер за счёт заголовка и границ окна.
Так же в коне присутствует небольшая панель, при нажатии разворачивающаяся в панель навигации. При этом сокращается область просмотра, а размеры окна не меняются. Размеры окна изменяемы (имеется ввиду пользователем, при помощи мыши).

IE 6
Открыл окно с областью просмотра 640×480 пикселей. Само окно превышает заданный размер за счёт заголовка и границ окна. Размеры окна НЕ изменяемы.

Теперь я задал окну размеры, заведомо превышающие разрешение монитора.

FireFox 3, Navigator 9, Konqueror
Открыли окно, развёрнутое на весь рабочий стол. В FF3 в окне отображается строка состояния и адресная строка (неактивная).

Opera 9
Открыла новую вкладку.

IE 6
Открыл окно, закрывшее собой весь экран, включая все панели (задач, меню и т.д.). Заголовок окна за пределами экрана.

Выводы

1. Все браузеры расценивают заданный размер как размер области просмотра.
2. Реальные размеры окна всегда больше заданных, причём разница варьируется для разных браузеров, за счёт наличия дополнительных панелей.
3. В Internet Explorer 6 нельзя вручную изменить размеры окна. Кстати, это правильное поведение window.open, т.к. все параметры, не указанные в вызове этой функции должны считаться равными «no» (включая resizable). Хотя это и не всегда удобно с точки зрения пользователя.
4. Необходимо следить за размером открываемого окна, т.к. при большом размере в IE6 оно может перекрыть пользователю весь рабочий стол

3. Позиционирование

Следующие на очереди — координаты окна. Для этого существуют две пары свойств — left и top в IE и screenX и screenY для NN.
Поочерёдно я попробовал каждую пару во всех браузерах.

window.open(‘http://www.w3.org/’, ‘popup’, ‘width=320,height=240,left=50,top=50’);

FireFox 3, Navigator 9, IE6, Konqueror
Все четыре браузера поняли свойства left и top и спозиционировали окно относительно верхнего левого угла экрана.
Не смотря на эту точку отсчёта, ни один из браузеров, при top = 0 не смог перекрыть окном панель меню.

Opera 9
Тоже поняла свойства left и top, но позиционировала окно относительно своей панели вкладок (отсчёт идёт от нижнего края).

window.open(‘http://www.w3.org/’, ‘popup’, ‘width=320,height=240,screenX=50,screenY=50’);

Эти свойства поняли только Gecko-барузеры (FF и NN), Opera и IE их проигнорировали.

Интересно поведение при попытке задать позицию явно превышающую размеры экрана.

window.open(‘http://www.w3.org/’, ‘popup’, ‘width=320,height=240,left=2000,top=1000’);

FireFox 3, Navigator 9, Opera
Открыли окно в нижнем правом углу рабочего стола (Opera — своей рабочей области). Окно видно целиком. Панели не перекрыты.

Konqueror
Окрыл окно в верхнем левом углу рабочего стола. Панели не перекрыты.

IE6
Проверить не удалось. IE просто переставал открывать окна до принудительного снятия процесса.

Выводы

1. Для позиционирования окна следует использовать свойства left и top, т.к. их понимают все барузеры.
2. Opera позиционирует окна не относительно экрана, а относительно своей панели вкладок.
3. Лучше стараться избегать ситуаций когда окно не поместится на рабочем столе, т.к. поведение браузеров разнится.

4. Элементы интерфейса

Последними я проверил управление элементами интерфейса (исключив элементы, специфичные для конкретного браузера):

• location — поле для набора URL
• menubar — панель меню
• scrollbars — полосы прокрутки
• status — строка состояния
• toolbar — панель с кнопками Back, Forward, Reload и т.д.

Каждый параметр пробовался как со значением yes, так и no.

FireFox 3

• location — отображается всегда и всегда неактивно, параметр игнорируется
• menubar — отображается главное меню
• scrollbars — появляются полосы прокрутки
• status — игнорируется, строка состояния показывается всегда
• toolbar — строка URL страла активной, появилась панель вкладок и дополнительные панели (WebDeveloper)

Navigator 9

• location — отображается неактивным. Дополнительно отобразилась одна из панелей инструментов (WebDeveloper)
• menubar — отображается главное меню
• scrollbars — появляются полосы прокрутки
• status — появляется строка состояния
• toolbar — строка URL страла активной, появилась панель вкладок и дополнительные панели (WebDeveloper)

Opera 9

• location — отображается активное поле ввода и кнопки «Назад», «Вперёд» и т.д.
• menubar — игнорируется
• scrollbars — появляются полосы прокрутки
• status — игнорируется
• toolbar — игнорируется

IE 6

• location — отображается активное поле ввода, главное меню и кнопки «Назад», «Вперёд» и т.д.
• menubar — отображается главное меню
• scrollbars — появляются полосы прокрутки
• status — появляется строка состояния
• toolbar — отображается главное меню и панель инструментов

Konqueror

• location — отображается всегда и всегда неактивно, параметр игнорируется
• menubar — отображается главное меню и панель инструментов
• scrollbars — появляются полосы прокрутки
• status — появляется строка состояния
• toolbar — отображается главное меню и панель инструментов

Выводы предоставляю делать самим. Хотя на мой взгляд, IE здесь демонстрирует более правильную реализацию функции window.open.

Проверить свой браузер

Safari

(спасибо qnick)
Safari 3.0.4 (5523.15), mac os 10.5.2
От галочки «Блокировать всплывающие окна» поведение не меняется абсолютно. Если ссылки жать вместе с яблоком (принудительное открытие окна в новой вкладке), то все равно появляются новые окна.

Без параметров: размеры по умолчанию, позиция на 32 пикселя (примерно, на глаз) ниже и правее текущего окна (но если нижняя граница текущего окна очень близко находится от нижней границы экрана, то у нового окна top=0), тулбар, скролл и статусная строка в наличии, окно тянется во все стороны

Размеры 640х480: исчезли тулбар, скролл и статусная строка, окно перестало тянуться. Позиция на 32 пикселя ниже и правее текущего (или top=0, см. выше), размеры 640х480 + 32 пиксела заголовка.

Очень большой размер: размер изменился на 1440х900 (разрешение экрана), top=0 независимо от положения текущего окна. Все остальное по прежнему.

Позиционирование: отсчет идет от верхнего левого угла минус меню, т.е.

В стиле Netscape: то же самое

Вне рабочего стола: left=0, top=0

Location: появилась адресная строка и тулбар, скролла нет, размеры менять нельзя.

Menubar: игнорируется, т.е. аналогично размеру 640х480.

Scrollbars: то же, что и размер 640х480, но появился вертикальный скролл

Status: то же, что и размер 640х480, но появился статусбар.

Toolbar: то же, что и location.

Окончанние

Будет очень здорово, если кто-нибудь дополнит тестами на других браузерах и платформах, в первую очередь конечно в Ineternet Explorer 7 под Windows.

Show multiple views for an app

Help your users be more productive by letting them view independent parts of your app in separate windows. When you create multiple windows for an app, the taskbar shows each window separately. Users can move, resize, show, and hide app windows independently and can switch between app windows as if they were separate apps.

When should an app use multiple views?

There are a variety of scenarios that can benefit from multiple views. Here are a few examples:

• An email app that lets users view a list of received messages while composing a new email
• An address book app that lets users compare contact info for multiple people side-by-side
• A music player app that lets users see what’s playing while browsing through a list of other available music
• A note-taking app that lets users copy information from one page of notes to another
• A reading app that lets users open several articles for reading later, after an opportunity to peruse all high-level headlines

While each app layout is unique, we recommend including a «new window» button in a predictable location, such as the top right corner of the content that can be opened in a new window. Also consider including a context menu option to «Open in a new window».

To create separate instances of your app (rather than separate windows for the same instance), see Create a multi-instance Windows app.

Windowing hosts

There are different ways that Windows content can be hosted inside an app.

An app view is the 1:1 pairing of a thread and a window that the app uses to display content. The first view that’s created when your app starts is called the main view. Each CoreWindow/ApplicationView operates in its own thread. Having to work on different UI threads can complicate multi-window apps.

The main view for your app is always hosted in an ApplicationView. Content in a secondary window can be hosted in a ApplicationView or in an AppWindow.

To learn how to use ApplicationView to show secondary windows in your app, see Use ApplicationView.

AppWindow simplifies the creation of multi-window Windows apps because it operates on the same UI thread that it’s created from.

The AppWindow class and other APIs in the WindowManagement namespace are available starting in Windows 10, version 1903 (SDK 18362). If your app targets earlier versions of Windows 10, you must use ApplicationView to create secondary windows.

To learn how to use AppWindow to show secondary windows in your app, see Use AppWindow.

AppWindow is currently in preview. This means you can submit apps that use AppWindow to the Store, but some platform and framework components are known to not work with AppWindow (see Limitations).

UWP XAML content in a Win32 app (using HWND), also known as XAML Islands, is hosted in a DesktopWindowXamlSource.

Make code portable across windowing hosts

When XAML content is displayed in a CoreWindow, there’s always an associated ApplicationView and XAML Window. You can use APIs on these classes to get information such as the window bounds. To retrieve an instance of these classes, you use the static CoreWindow.GetForCurrentThread method, ApplicationView.GetForCurrentView method, or Window.Current property. In addition, there are many classes that use the GetForCurrentView pattern to retrieve an instance of the class, such as DisplayInformation.GetForCurrentView.

These APIs work because there is only a single tree of XAML content for a CoreWindow/ApplicationView, so the XAML knows the context in which it’s hosted is that CoreWindow/ApplicationView.

When XAML content is running inside an AppWindow or DesktopWindowXamlSource, you can have multiple trees of XAML content running on the same thread at the same time. In this case, these APIs don’t give the right information, since the content is no longer running inside the current CoreWindow/ApplicationView (and XAML Window).

To ensure that your code works correctly across all windowing hosts, you should replace APIs that rely on CoreWindow, ApplicationView, and Window with new APIs that get their context from the XamlRoot class. The XamlRoot class represents a tree of XAML content and information about the context in which it is hosted, whether it’s a CoreWindow, AppWindow, or DesktopWindowXamlSource. This abstraction layer lets you write the same code regardless of which windowing host the XAML runs in.

This table shows code that does not work correctly across windowing hosts, and the new portable code that you can replace it with, as well as some APIs that you don’t need to change.

If you used.	Replace with.
CoreWindow.GetForCurrentThread().Bounds	uiElement.XamlRoot.Size
CoreWindow.GetForCurrentThread().SizeChanged	uiElement.XamlRoot.Changed
CoreWindow.Visible	uiElement.XamlRoot.IsHostVisible
CoreWindow.VisibilityChanged	uiElement.XamlRoot.Changed
CoreWindow.GetForCurrentThread().GetKeyState	Unchanged. This is supported in AppWindow and DesktopWindowXamlSource.
CoreWindow.GetForCurrentThread().GetAsyncKeyState	Unchanged. This is supported in AppWindow and DesktopWindowXamlSource.
Window.Current	Returns the main XAML Window object which is closely bound to the current CoreWindow. See Note after this table.
Window.Current.Bounds	uiElement.XamlRoot.Size
Window.Current.Content	UIElement root = uiElement.XamlRoot.Content
Window.Current.Compositor	Unchanged. This is supported in AppWindow and DesktopWindowXamlSource.
VisualTreeHelper.FindElementsInHostCoordinates Although the UIElement param is optional, the method raises an exception if a UIElement isn’t supplied when hosted on an Island.	Specify the uiElement.XamlRoot as UIElement instead of leaving it blank.
VisualTreeHelper.GetOpenPopups In XAML Islands apps this will throw an error. In AppWindow apps this will return open popups on the main window.	VisualTreeHelper.GetOpenPopupsForXamlRoot(uiElement.XamlRoot)
FocusManager.GetFocusedElement	FocusManager.GetFocusedElement(uiElement.XamlRoot)
contentDialog.ShowAsync()	contentDialog.XamlRoot = uiElement.XamlRoot; contentDialog.ShowAsync();
menuFlyout.ShowAt(null, new Point(10, 10));	menuFlyout.XamlRoot = uiElement.XamlRoot; menuFlyout.ShowAt(null, new Point(10, 10));

For XAML content in a DesktopWindowXamlSource, there does exist a CoreWindow/Window on the thread, but it is always invisible and has a size of 1×1. It is still accessible to the app but won’t return meaningful bounds or visibility.

For XAML content in an AppWindow, there will always be exactly one CoreWindow on the same thread. If you call a GetForCurrentView or GetForCurrentThread API, that API will return an object that reflects the state of the CoreWindow on the thread, not any of the AppWindows that may be running on that thread.