A signal is a special member function declared in a class declaration. It can have a
parameter list but no function body. It cannot be called but can be emitted by an
instance of the class.
A slot is a special void member function that can be connected to a signal. Then
when the signal is emitted, the slot is called. A slot can also be called as a normal
member function.
can signal and slots work across objects of different classes?
They can indeed work across objects of different classes, that's the whole point.
Qt uses signals and slots quite extensively, look at their description:
Qt Signals and Slots
Related
I'm purely curious (high level explanation) how mobx.autorun() is smart enough to grovel through the function it's passed to determine which observables are accessed?
The short story is that autorun does not parse your code looking for usages, but rather records each access of an observable within the first run. This is why it must run once straight away.
It has wrapped the getter and setter of each observable so that it can record which ones you use (via the getter) and build a list of observables that your autorun function used. If any of them change (via the setter), it will detect that and rerun your autorun function.
I'm experimenting in Pharo and I was wondering how class, instance variable scope is achieved.
More to the point, instance variables can be accessed by all the methods of that instance of a class, also class instance variables can be accessed by all the methods of the class and so on.
Where does the depth of this scope get defined in code? Can one see where and how this takes place, Smalltalk being fully Object Oriented?
I presume you are in Pharo >= 4.0, in which case you have the so called OpalCompiler.
In OpalCompiler, the variable scope is reified (see OCAbstractScope and subclasses), the scope being used during semantic analysis of the Abstract Syntax Tree (see OCASTSemanticAnalyzer).
You now have an entry point, and should follow message senders, class refs, instance variable refs, ... from this starting point.
I'm using Spine.js from plain Javascript (no Coffescript).
I'm using the syntax described in the documentation to call a parent class method.
Specifically: this.constructor.__super__.someFunction.apply(this, arguments)
This works fine for a direct child class calling it's immediate parent class. But add a grand-child class and all hell breaks loose. Calling the method on an instance of the grand-child class results in an infinite loop. I have a jsFiddle that demonstrates this by implementing the class hierarchy shown here:
MyObjClass (implements method sayHi())
^
|
My2ndObjClass (method sayHi() calls superclass)
^
|
My3rdObjClass
When sayHi() is called on an instance of My3rdObjClass you get an infinite loop (the Chrome console reports max stack error).
My guess is that when sayHi() runs on My3rdObj it naturally runs the parent class implementation (so, My2ndObjClass's sayHi() executes). My2ndObjClass's sayHi() then resolves super to be My2ndObjClass rather than MyObjClass (as I expected), so the call to super now becomes a recursive call, and away we go... a StackOverflow ;)
So, am I doing something wrong, or is this a limitation of Spine? I suspect there's some clever way to get around this, but I haven't found it via Google or by RTFM.
2 things: "this" isn't what you think it is. The scoping of "this" does not follow traditional language constructs, so you need to reference the specific variable in the closure you want. In this case "my2ndObjClass".
Second, since you're using "include", your methods are defined on the instance, not the class. In the coffeescript/javascript uses of prototypes/objects, it's whether the thing you're looking for is in the constructor, object itself. So don't look in the constructor' super, just in the object's directly.
So, your definition
my2ndObjClass.include({
sayHi: function() {
this.constructor.__super__.sayHi.apply(this,arguments);
}
});
becomes
my2ndObjClass.include({
sayHi: function() {
my2ndObjClass.__super__.sayHi.apply(this,arguments);
}
});
And it works.
IMHO, these are all the reasons to to use coffeescript, to avoid all this brittleness and convention
I need to call the co-class function by reading its address from vtable of COM exposed interface methods. I need some generic way to read addresses.
Now I need to call the function, which would have specific address(NOT KNOWN) arguments(parameters) which I have collected from TLB, and name as well. How that address corresponds to that function name to which I am going to call.
For this I need to traverse vtable which is holding functional addresses, LASTLY need to correspond function address with NAME of that function. This is I dont know. How? More over one function with the same name may appear in vtable(Overloading case). In that case we need to distinguish function names w.r.t their addresses. How to tackle ?
Regards
Usman
Respectfully Sir.!!
I am designing a Unit Testing framework for which I need to pull out all function signatures of certain COM Exe or COM DLL to show in the grid or whatever interface to user, so that later by selecting certain function signature from that list, He/She can execute that function after providing the arguments(data as parameters) to that function. All this would be done dynamically at runtime, on runtime function will be called whatever user wants.
This can be achieved from various ways.
By providing TLB(Type libraries) we can pull every function signature and can show every signature to Grid control or on Tree control. Second step is to call these functions at runtime by providing data. Calling require data and address of functions(or Names). I would have some GUI panel or control which will take the data from user and that data would then become as arguments.
Now real problem comes for which I posted earlier. Call to functions/methods of that interface exposed by COM component implemented by co-class. This requires to trail down vtable of interface exposed by component , finding the address of that function and then need to know IS IT REALLY THAT ADDRESS TO WHICH I AM GOING TO CALL AS FUNCTION? So this requires to translate that address to function name and then comparison some string comparison would decide that whether it was really that function name which USER CLICKED from Tree Control showing signatures.
Suggestions or reccommendations?
Call ITypeInfo::GetFuncDesc for each function and the FUNCDESC structure you get back contains the vtable index in the oVft member. Cast an interfaces vtable to void** and just use it as an index.
Of course quite why you need to do this I do not know :)
Is there possible to create a COM-instance in it's own, dedicated, host-process?
I guess some background is needed.
We have an end-user client which has it's central logical components inside an singleton-COM object. (Not propper singleton, but it uses global variables internally, so it would fail.) So that there should be only one instance per exe-file. Convenient while making the client.
However, I should now make a "client-simulator" to test the server-side. I therefore which to make 20 instances of the client-component.
If I could make each instance instanciate in its own exe-host, then the singleton-issue would be handled.
Regards
Leif
I have been struggling with this problem for a few days. I finally found a solution that works. My COM object is written using ATL, so my code snippet will be geared toward that, but the technical solution should be clear. It all hinges on how the class objects are registered. The REGCLS_SINGLEUSE flag is the key. I now have separate processes for each object instance.
In the ATL module, override the RegisterClassObjects() function as follows:
HRESULT RegisterClassObjects(DWORD dwClsContext, DWORD dwFlags) throw()
{
return base::RegisterClassObjects(CLSCTX_LOCAL_SERVER, REGCLS_SUSPENDED | REGCLS_SINGLEUSE);
}
From MSDN regarding REGCLS_SINGLEUSE:
REGCLS_SINGLEUSE
After an application is connected to a class object with
CoGetClassObject, the class object is removed from public view so that
no other applications can connect to it. This value is commonly used
for single document interface (SDI) applications. Specifying this
value does not affect the responsibility of the object application to
call CoRevokeClassObject; it must always call CoRevokeClassObject when
it is finished with an object class.
My theory is that because the registration was removed from public view, it causes a new process to be created for the subsequent instantiations.
This other question mentioned a description of how to use DLLHost as a surrogate process:
http://support.microsoft.com/kb/198891
I've never tried this myself, and I don't know off-hand if you can specify flags for the factories (which control if surrogates can be reused for multiple objects), but maybe you can tweak that via DCOMCNFG or OLEVIEW.
My COM days are long gone, but as far as I remember, there's no built-in way to do that.
It might be easier to rewrite your code so it supports multiple instances than to go the one-process-per-instance route with COM, but here's what you could do:
Use thread-local storage for your global variables and write another CoClass, where each instance owns its own thread through which accesses to the class with the global variables are marshaled. This would at least allow you to avoid the performance impact of DCOM.
Write your own out-of-process exe server (similar to windows' DllHost.exe) to host your COM instances. This requires IPC (Inter-Process Communication), so you either have to code something yourself that marshals calls to the external process or use DCOM (presuming your COM object implements IDispatch)