Using VMR7 and VMR9, I can query interface from renderer for IVMRMonitorConfig[9] to ask monitor related informations via IVMRMonitorConfig::GetAvailableMonitors(). My purpose is to check the what underlying VGA of renderer by checking the keyword in VMRMONITORINFO[9]::szDescription. ex: nvidia.
For EVR, everything is new and different. I try to find the interface providing monitor related or something with hardware information. Here is what I've looked up but not wanted.
IEVRFilterConfig provides static configuration
IMFVideoRenderer provides service that reset new presenter
IMFVideoDeviceID(RENDER_SERVICE) provides Device GUID. But it looks like generally gives IID_IDirect3DDevice9 as return.
IMFVideoDisplayControl provides output window control and query
Related
I have import a dump file from .NET Core process into WinDbg.
There is an event handle
0:000> !handle 3760 f
Handle 0000000000003760
Type Event
Attributes 0
GrantedAccess 0x1f0003:
Delete,ReadControl,WriteDac,WriteOwner,Synch
QueryState,ModifyState
HandleCount 2
PointerCount 65534
Name <none>
Object specific information
Event Type Auto Reset
Event is Waiting
How can I use the SOS extension to analyze this event? To see where it is created in managed code?
As Event Type is Auto Reset, imho you should look at the instances of AutoResetEvent class.
Not sure about Core but in Framework you can take NetExt extension and perform queries to the heap.
AutoResetEvent has a private field waitHandle with IntPtr to the handle you observe.
So, after running !windex NexExt query will look like:
!wfrom -type System.Threading.AutoResetEvent where (waitHandle == 0000000000003760) select $addr(), $tohexstring(waitHandle)
If NetExt doesn't work with Core you can dump all instances on AutoResetEvents into text file like this and then find your event there.
.logopen c:\temp\autoresetevents.txt
.foreach (obj {!dumpheap -type AutoResetEvent -short}) {!do obj}
.logclose
With this approach you'll be able to find managed object that corresponds to the handle.
You'll also be able to see the roots with !GCRoot. But you won't be able to see where it is created.
You'll need to search around.
Or you'll need to use different approach, something with PerfView allocation tracing or maybe some special breakpoints.
Why it uses d->eventFilters.prepend(obj) not append(obj) in function(QObject::installEventFilter),i want to know why design it in such way.I just curious about it.
void QObject::installEventFilter(QObject *obj)
{
Q_D(QObject);
if (!obj)
return;
if (d->threadData != obj->d_func()->threadData) {
qWarning("QObject::installEventFilter(): Cannot filter events for objects in a different thread.");
return;
}
// clean up unused items in the list
d->eventFilters.removeAll((QObject*)0);
d->eventFilters.removeAll(obj);
d->eventFilters.prepend(obj);
}
It's done that way because the most recently installed event filter is to be processed first, i.e. it needs to be at the beginning of the filter list. The filters are invoked by traversing the list in sequential order from begin() to end().
The most recently installed filter is to be processed first because the only two simple choices are to either process it first or last. And the second choice is not useful: when you filter events, you want to decide what happens before anyone else does. Well, but then some new user's filter will go before yours, so how that can be? As follows: event filters are used to amend functionality - functionality that already exists. If you added a filter somewhere inside the existing functionality, you'd effectively be interfacing to a partially defined system, with unknown behavior. After all, even Qt's implementation uses event filters. They provide the documented behavior. By inserting your event filter last, you couldn't be sure at all what events it will see - it'd all depend on implementation details of every layer of functionality above your filter.
A system with some event filter installed is like a layer of skin on the onion - the user of that system only sees the skin, not what's inside, not the implementation. But they can add their own skin on top if they wish so, and implement new functionality that way. They can't dig into the onion, because they don't know what's in it. Of course that's a generalization: they don't know because it doesn't form an API, a contract between them and the implementation of the system. They are free to read the source code and/or reverse engineer the system, and then insert the event filter anywhere in the list they wish. After all, once you get access to QObjectPrivate, you can modify the event filter list as you wish. But then you're responsible for the behavior of not only what you added on top of the public API, but of many of the underlying layers too - and your responsibility broadens. Updating the toolkit becomes next to impossible, because you'd have to audit the code and/or verify test coverage to make sure that something somewhere in the internals didn't get broken.
I want to inject a BroadcasterFactory into a Publisher-style class before I have constructed my Nettosphere via it's builders. But a call to BroadcasterFactory.getDefault() returns null before it's initialized via the construction of my Nettosphere. I guess I could build a BroadcasterFactory myself first, but that seems to be messing with the Nettosphere construction process.
At a high level I want access to Broadcasters (1 per connection) from the backend in order to push individual messages to clients.
I could do my own map of broadcasters, but broadcasterfactory already does this and I don't really want to have to manage 2 stores of broadcasters.
Thanks :)
Which version of Atmosphere are you using?
Just tested with 2.0.0-SNAPSHOT and it worked.
I suspect they were a regression before.
Im using RobotLegs and Signals for my application. This is my first time using Robotlegs, and Im using Joel Hooks Signal Command Map example here
I've noticed that it seems quite verbose in contrast to events. For every Signal I have to create a new class, whereas with events I would group event types into one class.
I like how visually and instantly descriptive this is.. just browsing a signals package will reveal all app communications. Although it seems quite verbose to me.
Are other people using this, Is the way I'm using signals like this correct, or have people found a way around this verboseness?
Cheers
It's the correct way though. The major advantage of signals is you can include them in your interface definitions, but obviously you'll end up with a big pile of signals.
In general I use signals only for my view->mediator and service->command communication (1-to-1). For system wide notifications I use events (n-to-n). It makes the number of signals a bit more manageable.
But it's a matter of preference obviously.
Using a good IDE and/or a templating system alleviates a lot of the "pain" of having to create the various signals.
You do not have to make a new signal class for Command maps, its just good practice. You could just give the "dataType" class a type property - and do a switch on that. But that would be messy for commands. But note, Commands are basically for triggering application wide actions.
Not all signals trigger application wide actions.
For instance, if you are responding to a heap of events from a single View. I suggest making a Signal class for related "view events" (e.g. MyButtonSignal for MyButtonView) and give it a type property.
A typical signal of mine will look like:
package {
public class MyButtonSignal extends Signal {
public static const CLICK:String = 'myButtonClick';
public static const OVER:String = 'myButtonOver';
public function MyButtonSignal() {
super(String, Object);
}
}
}
Dispatch like so
myButtonSignal.dispatch(MyButtonSignal.CLICK, {name:'exit'});
Listen as normal:
myButtonSignal.add(doMyButtonSignal);
Handle signal like so:
protected function doMyButtonSignal(type:String, params:Object):void {
switch(type) {
case MyButtonSignal.CLICK: trace('click', params.name);
break;
case MyButtonSignal.OVER: trace('OVER', params.name);
break;
}
}
Occasionally its useful to give the data variable its own data class.
So everytime you realise "Aw shit, I need to react to another event", you simple go to the Signal and add a new static const to represent the event. Much like you (probably?) did when using Event objects.
For every Signal I have to create a new class, whereas with events I
would group event types into one class.
Instead of doing that you could just use the signal as a property… something like:
public var myCustomSignal:Signal = new Signal(String,String);
You can think of a signal as a property of your object/interface.
In Joel's example he's using signals to denote system level events and is mapping them with the robotlegs SignalMap which maps signals by type. Because they are mapped by type you need to create a unique type for each system level signal.
Morning all,
How would I go about getting the serial number of the storage/sd card on my mobile device? I am using C#.Net 2.0 on the Compact Framework V2.0.
Thanks.
The Smart Device Framework provides a mechanism to get SD Card serial numbers and manufacturer IDs.
I'm not on a machine that I can get the syntax for you but I believe you can use the System.IO namespace to get IO based attributes.
First get a DirectoryInfo to the storage card. (I'm not 100% on the code here, you may need to test, I'll update it if I can get to my machine)
public DirectoryInfo GetStorageCard() {
DirectoryInfo deviceRoot = new DirectoryInfo("/");
foreach (DirectoryInfo dir in deviceRoot.GetDirectories())
if (dir.Attributes == FileAttributes.Directory & dir.Attributes = FileAttributes.Temporary)
return dir;
}
Then check all the properties on the DirectoryInfo that code returns. Thanks to the joys of debugging you should be able to see if the serial number is one of the available properties.
If not, you may need to look to something a bit more unmanaged.
Hope this helps.
You need to use some unmanaged APIs. Specifically, DeviceIoControl using a 'control code' of IOCT_DISK_GET_STORAGEID. This will, in turn, return a STORAGE_IDENTIFICATION structure.
Here's where it gets a bit tricky, as STORAGE_IDENTIFICATION uses a property (dwSerialNumOffset) to specify the (memory) offset from the beginning of the structure, which would be difficult to translate into interop calls.
Edit: Found a VB.NET implementation on the MSDN forums