I have developed an application in X/Motif that has a performance issue related with the standard Drag&Drop functionality supplied by the toolkit. I have already disabled the Drag&Drop protocol at the level of the user interface by setting the XmDRAG_NONE resources:
dragInitiatorProtocolStyle: XmDRAG_NONE
dragReceiverProtocolStyle: XmDRAG_NONE
This effectively disables the Drag&Drop HMI standard features, but the properties / atoms’ (in _MOTIF_DRAG_WINDOW) related to this functionality continue to be created in the Root Window every time widgets such as XmText (or others with Drag&Drop capability) are instantiated by the application.
Is there a way to force a complete disable of the Drag&Drop?
If not, is there a way to safely remove the Drag&Drop properties/atoms in the Root Window?
Thanks in advance.
Related
There is any way to access sharing extensions without popping the default UIActivityViewController?
I couldn't find one, but asking just in case.
In case not, i have another question.
How are you planing to adapt your app's custom sharing interfaces to this restriction?
You cannot access Share/Action extensions without using UIActivityViewController. In iOS8 sharing area of the activity view controller is the only entry point for share extensions.
From Apple docs.
Each of which is tied to an area of the system, such as sharing,
Notification Center, and the iOS keyboard. A system area that supports
extensions is called an extension point. Each extension point defines
usage policies and provides APIs that you use when you create an
extension for that area. You choose an extension point to use based on
the functionality you want to provide.
The best you can do is to provide a share menu with two options to launch app's custom sharing interface and UIActivityViewController. Bad UX but I don't know any other way.
I wanted to know the difference among following control and classes.
Windows Browser Control Vs CDHtmlDialog and CHtmlView.
It is visible that these things are used to add html content in UI for
windows based application.
But when we search in internet one will often confused with these things.
It would be good if some explain the usability of these Control and Classes.
The Web Browser Control is a Windows ActiveX control that is probably used by Internet Explorer itself to display HTML contents. At the very least, Web Browser Control and Internet Explorer use the same implementation for rendering HTML.
CHtmlView is a MFC - CView -derived class hosting said ActiveX control.
CHtmlDialog is a MFC - CDialog - derived class doing the same.
They are separate classes because unfortunately MFC has a "huge gap" between dialogs, views and windows.
I haven't worked significantly with either MFC class but in my understanding they don't add any functionality by themselves. You can as well host the web browser control like a normal ActiveX and use GetControlUnknown to acquire IWebBrowser interface.
The biggest problem in my experience is that DOM is only accessible after DocumentComplete, and that event won't fire before the message loop doesn't pump. This makes some operations rather painful I ended up with a custom interface queuing modifications until DOM is available.
P.S. Windows now offers the WebView2 - ActiveX control, based on Edge, as a sufficient and powerful replacement. see https://learn.microsoft.com/en-us/microsoft-edge/webview2/
I have built a wizard style user control that lets you add stackpanel based pages and flick between them.
I would like to add an application bar as part of the user control with next and previous buttons that enable/disable based on page displayed etc.
Application bar appears to be an attached property of PhoneApplicationPage. I have tried referencing Microsoft.Phone.Shell but get invalid type.
Any ideas how I can add it to my user control?
Application bar is such a pain in the a**. This control is not a Silverlight one but a native one. Maybe you can be more lucky with this solution:
http://blog.humann.info/post/2010/08/27/How-to-have-binding-on-the-ApplicationBar.aspx
The ApplicationBar is a service that is provided by the operating system, i.e. not part of the Framework, and can only be used at the page-level, not in your UserControl. In addition, the ApplicationBar does not support regular bindings as you've seen. As mentioned above there are a number of solutions that provide workarounds for this problem.
Alternatively, you could use the ApplicationBarButtonCommand and ApplicationBarButtonNavigation behaviors from the Silverlight Windows Phone Toolkit. It's a simple enough task to create your ApplicationBarMenuCommand if you need one.
Valve's game manager application, Steam, has a very unique user interface, with custom buttons and windows. How would you create a Win32 application that has such a look?
Pretty much every windows common control supports custom and/or owner draw (not the exact same thing), that just leaves the dialog itself where you can customize its look by handling WM_ERASEBKGND and WM_PAINT or WM_NCCALCSIZE,WM_NCPAINT (If you don't want native titlebars and border etc)
As you can see, to do a custom GUI requires you to paint every control yourself... (And keep in mind that a lot of people hate skinned apps and would rather just have a native looking app)
We need to automate GUI testing of an application developed in Win32 API. Developer's have created this application by custom painted controls. They have controls which look like Grid, Buttons etc., but they are not basic Windows controls.
What is custom painted controls? and how we can test these controls?
Test it just like any other UI: Not at all. Move all code out of the callbacks into the application layer where your unit tests can execute them just like any other method.
Rationale: There is little point in testing whether "button.activate()" works; you want to know whether the your code behind the button callback works.
If you need to know whether the correct dialogs, etc., are opened, see my blog: Testing the Impossible: User Dialogs
Have the developers added support for accessibility using IAccessible? If they have, you can use active accessibility to navigate through the controls and test them that way.
If they haven't, open a bug that says that their controls can't be use by disabled people (who need a screen reader or other accessibility aid).
Once they fix that bug, you can use whatever mechanism they added to their controls to allow them to be used by screen readers and other accessibility aids to test their UI.