I have written an DirectShow-Filter *.ax to integrate a Hardware (Camera). All works fine with my filter.ax and there Transport Images to Skype success.
Now I am want to integrate a Dialog to handle the camera-options with UI.
In my Filter.ax is calling the function QueryInterface(REFIID riid, void **ppv)
when riid == IID_ISpecifyPropertyPages
I am have seen that the Dialog must be in a other DLL like Com ?
My try to open the Dialog directly works, but no windows Messages are incoming.
I must also write an MFC Dll they is starting by PropertyPage IIID ? My Propertypage is a large MFC Controles TabControl with some items. I can see it if i start the filter from MFC Test app. AfxInit I can't execute. (Wrong Lib versions I must use the directshow baseclass(knowledge example)
I don't now why my Dialog got no Messages, what is the right way ?
You don't need to implement a property page in a separate DLL (even though it is a possible).
DirectShow filter property pages are regular COM property pages implemented using ISpecifyPropertyPages. Property pages are separate COM objects implementing well known interfaces like IPropertyPage.
Windows SDK Ezrgb24 sample shows how to implement a simple transform filter and also features a property page (CEZrgb24Properties class). It should be a good start for a property page implementation for your filter.
If you prefer to implement the property page in a separate DLL, a typical way is to define a shared COM interface, the filter would implement it and reference the property page by its CLSID, the property page would query this interface from the filter instance and use it for configuration actions.
Related
How do you display the Oil/Water/Gas components of a BlackOil domain object programatically on the FunctionWindow? I tried calling FunctionWindow.ShowObject on BlackOil.OilPhase but received an error that it could not be found on the input tree.
I need to say sorry here, but this is the bad case when you can get an programmatically access to the object via FluidFunctionCollection (you can create/update it), but you cannot get access to the same object via InputTree interface (you will receive an UnknownEntity via GetType method when try to navigate from Petrel UI to this object type and send it to your plug-in (doesn't exposed for Ocean from this site yet)), and by this reason you cannot display this object programmatically. I submitted an internal ticket for your case.
Converting a WPF application from .Net 4.0 to Metro.
It uses HeaderedItemsControl in various places.
I have not been able to find that control or a replacement candidate in Metro (Windows.UI.Xaml namespace)
So what is the recommended control in Metro to provide the functionality of HeaderedItemsControl?
You could easily create one by deriving from ItemsControl and adding a few simple dependency properties. You can see which properties are present in the WPF version here. You might not need all of them, but from a quick glance I can see a Header property which is just an object type. You would put a ContentPresenter in your HeaderedItemsControl's ControlTemplate and bind its Content to the HeaderProperty using TemplateBinding. Then bind the HeaderTemplate to the ContentTemplate of the ContentPresenter, etc.
Not sure how useful it is though to port WPF XAML code directly to WinRT. You're just asking for trouble in terms of code compatibility, but also porting a likely desktop-designed UI to a more touch-centric world.
I’m looking for alternative for existing tests written in QTP for my Win32 application written in Borland C++.
My candidate is White which based on UI Automation because it’s native solution,
I can create my tests using .NET/C# and easily integrate it with nUnit and Hudson.
White
http://white.codeplex.com
MS UI Automation
http://msdn.microsoft.com/en-us/library/ms747327.aspx
UI Verify
http://uiautomationverify.codeplex.com
I use UI Verify as a spy to identify properties of objects I want to find in my tests.
More or less when I can see something in the spy, I can find it using UI Automation/White.
Generally I don't have much problems with recognizing objects
but when I try to search some content inside the tab contained in Tab Panel
or try to see MenuItems of Menu bar then the problem appears.
UI Automation/UI Verify works wired. When I run UI Verify (1.0 version) I see that objects can be registered properly only then
when I set 'Focus tracking' option and click on target objects or change the keyboard cursor on them. Otherwise it's impossible to find them.
UI Verifier can show me children of my 'tab' panel then. But I can’t find them using UI Automation/White. This is example code:
Tab tab = window.Get();
ITabPage tabPage = tab.SelectedTab;
AutomationElementCollection newCol = tabPage.AutomationElement.FindAll(TreeScope.Descendants, Condition.TrueCondition);
window.Get("buttonName");
the collection is empty even though spy see the children.
Does any of you have some experience with White/UI Automation library that he/she would like to share with me?
I want to implement the tracking feature from the spy to my tests. Can you help me with that? I'm trying to study the code of UIA Verify spy. I think that there are two classes responsible for catching the objects: FocusChangeListener and FocusTracer - this is the code:
http://uiautomationverify.codeplex.com/SourceControl/changeset/view/9992#214260
http://uiautomationverify.codeplex.com/SourceControl/changeset/view/9992#214192
Requirements:
1. Windows SDK
2. .NET 3.5
3. White
4. UIA Verify code
Do you have any better alternative for White/UI Automation?
R.
Could you, the R or YoYo, put your form compiled or in source codes (preferable without the internal logic) somewhere on a file share?
I've never seen a control that'd be not caught using UI Automation if UIAVerify sees it. I saw such windows, which could be only caught with the Focus Tracking feature of UIAVerify. This case, such a window is untouchable by UI Automation search.
Regarding a control, are you sure that the controls you struggling with have the Name property? Maybe, this is a value available only by means of ValuePattern, not the Name?
I have a program that is getting pretty big and it is a pain to find everything through all the functions and classes.
I am trying to break it up into other files based on their method.
Some of these functions have calls to others in the main class. I changed most my functions from private to public to access this. I had problems calling certain code created windows so importing mainwindow helped that.
My last problem is editing the mainwindow ui from one of the module files. I want to make sure im on the right page before i continue breaking it up. My only guess is that anything they updates the ui should be left on the main class.
Thanks
The only code in your form class should be code that talks to other classes and updates the UI based on data from other classes.
Depending on your application, the form class might handle change events from other classes to update the UI or pass user input to other classes in Change or Click events.
A couple options:
Use callbacks into the your main window.
Create events for when you need the form updated. Your program logic raises the events, and your main window class can consume them.
I have a problem which is also related to AppDomain's and Windows messages.
A web page to be hosted in Internet Explorer that would contain a .Net WinForms UserControl derived control - HelloWorldCtl. This control is inside a C# written assembly - HelloWorldControl.dll. The control uses code from another assembly that is written in C++/CLR - HelloWorldLibCPP.dll.
HelloWorldCtl loads HelloWorldLibCPP.dll and calls code that would create a Win32 native window and places that window in HelloWorldCtl's area.
Navigate to the web page, HelloWorldCtl loads, I can see it as well as the native window in the center of HelloWorldCtl's area.
Both the C# control and the native window have some message handlers and the messages are all working fine and reaching both the C# control's window and the native window; mouse clicks, re-paints and so on... However, some of the message handlers of the native window need to call methods on the C# control which is the parent of the native window. This is done using an interface that the C# control implements and which the native window holds a reference to by storing it in a GCHandle (from System::Runtime::InteropServices.) I used the gcroot<> template for the GCHandle.
The failure is happening at this point when code in the native window is trying to use the GCHandle to call any method on the C# control. (The c++ code is compiled as managed code with /clr.)
The exception that is thrown is :
"Cannot pass a GCHandle across AppDomains"
I put some debugging code to display the Id and FriendName of the CurrentDomain in both the C# and the native window and I found out that these AppDomains are not the same.
During the creation of the native window, the CurrentDomain is the same as that of the C# control, but when the native window receives messages and those messages are handled, the CurrentDomain is different from the C# control's.
Can this situation be changed? Is it possible to have both the native window messages hanlder run in the same AppDomain as that of the C# control?
Any other suggestions perhaps?
Thanks,
Roger
I have actually found a solution for the problem in question indeed. I successfully implemented my code in a similar fashion to what is described in the following post from the "Thoughts from Mirality,
Random thoughts and musings from Miral at Mirality Systems" blog under the subject "Unmanaged callbacks across AppDomains".
Good Luck,
Roger
http://lambert.geek.nz/2007/05/29/unmanaged-appdomain-callback/