Is there any way of retrieving the double-click speed from the System Settings, preferably using C++ (CG APIs perhaps), otherwise an Objective-C example would also be acceptable.
I found that it's possible to get the scrolling direction using standardUserDefaults, but I haven't been able to find any documentation for this:
How to check scrolling direction of OSX with cocoa APIs
Note: I'm not looking for a Cocoa-specific solution. E.g. I don't think it's possible to retreive NSEvent.doubleClickInterval from a non-cocoa application. I might be wrong though.
Apparently HIToolbox has been deprecated and is not available for 64-bit applications. It seems the best solution is to link to the AppKit framework and wrap the Objective-C call doubleClickInterval of the NSEvent class. This works even for non-cocoa C++ applications just fine.
Linker Flags:
-framework AppKit
Foo.cpp:
#include "Utility.h"
void foo()
{
double doubleTimeInCppApp = GetDoubleTime();
...
}
Utility.h:
double GetDoubleTime();
Utility.mm:
double GetDoubleTime()
{
return [NSEvent doubleClickInterval];
}
I think it is here:
defaults read -g com.apple.mouse.scaling
Ooops, that is the tracking speed... hold on.
Related
How do I implement a function to load a dll(aka framework) on Mac OS using C++?
void LoadFramework(const char* frameworkPath)
{
//frameworkPath is the absolute path of the framework
}
Edit:
When I google searched for this problem, I mostly ended up with dlopen solution to load the framework. What I am instead looking for is to use CFBundleCreate to load the framework. It seems to me that there are a bunch of methods needed to be called to construct an URL from const char * path. I found the needed code in pieces, and could not write one comprehensive solution.
It typically is just a few lines of straightforward code to open a framework in Mac, something along the lines of :
bundleURL = CFURLCreateWithFileSystemPath(kCFAllocatorDefault,
CFSTR("/System/Library/Frameworks/<your_framework_name.framework>"),
kCFURLPOSIXPathStyle, true);
bundle = CFBundleCreate(kCFAllocatorDefault, bundleURL);
assert(bundle != NULL);
and pretty much everything in that snippet is well documented. I would suggest adding more detail in the question, as to the specifics of what exactly is not working for you.
Why not do this?
using DLL_Namespace;
This should give you access to the DLL.
I'm trying to intercept some native library-calls via LD_PRELOAD.
This is working fine for simple libraries written in C, but now I try to go further and override some more complex class-methods from the AOSP written in C++.
Here's my example:
#include <rs/cpp/util/RefBase.h>
namespace android {
sp<MediaCodec> MediaCodec::CreateByType(const sp<ALooper> &looper, const char *mime, bool encoder) {
// TODO this will be implemented by me
return NULL;
}
}
In my Application.mk, I got the following piece of code:
APP_STL := gnustl_static
and inside the Android.mk this one:
LOCAL_STATIC_LIBRARIES += libstlport_static
Sadly, the error I get is the following:
jni/libhook/ld_preload.cpp:88:1: error: 'sp' does not name a type
Anyone an idea how to use sp<..> here? I assume it's not Android-specific but a standard C++-thing - I'm totally new at C++, just started "today" :)
I know this may be bad practice, so I'm welcome for any other idea.
sp<> is Android-specific. sp<> is Strong Pointer, wp<> is Weak Pointer; they came into being as part of the Binder IPC implementation.
The place to start looking for the implementation is the framework RefBase.h, which is a bit twisty for a C++ newcomer. None of what you're fiddling with is part of the public API defined by the NDK, which means it's subject to change between releases, so be aware that what you're trying to do may not work across devices or software updates.
So...I have a kernel mode component and a user mode component I'm putting together using the turnkey build environment of the NT DDK 7.1.0. The kernel component is all .c/.h/.rc files. The user mode component is .cpp/.c/.h/.rc files.
At first it seemed simplest to use build for both, as I saw you could modify the ./sources file of the user mode component to say something like:
TARGETNAME = MyUserModeComponent
TARGETTYPE = PROGRAM
UMTYPE = windows
UMENTRY = winmain
USE_MSVCRT = 1
That didn't seem to cause a problem and so I was pleased, until I tried to #include <string> (or <memory>, or whatever) Doesn't find that stuff:
error C1083: Cannot open include file: 'string': No such file or directory
Still, it's compiling the user mode piece with C++ language semantics. But how do I get the standard includes to work?
I don't technically need to use the DDK build tool for the user mode piece. I could make a visual studio solution. I'm a bit wary as I have bumped into other annoyances, like the fact that the DDK uses __stdcall instead of __cdecl by default... and there isn't any pragma or compiler switch to override this. You literally have to go into each declaration you care about and change it, assuming you have source to do so. :-/
I'm starting to wonder if this is just a fractal descent into "just because you CAN doesn't mean you SHOULD build user mode apps with the DDK. Here be dragons." So my question isn't just about this particular technical hurdle, but rather if I should abandon the idea of building a C++ user mode component with the DDK tools...just because the kernel component is pure C.
To build a user mode program with WINDDK you need to add some variables to your SOURCES file:
386_STDCALL=0 to use cdecl calling convention by default
USE_STL=1 to use STL
USE_NATIVE_EH=1 to add a support for exception handling
Everything else you already have.
I'll put my full SOURCES file for reference:
TARGETNAME = MyUserModeComponent
TARGETTYPE = PROGRAM
TARGETPATH = obj
UMTYPE = console
UMENTRY = main
USE_MSVCRT = 1
USE_NATIVE_EH=1
USE_STL=1
386_STDCALL=0
SOURCES= main.cpp
And main.cpp:
#include <iostream>
#include <string>
using namespace std;
int main()
{
string s = "bla bla bla!";
cout << s;
return 0;
}
Have fun!
Quick Answer
Abandon the idea of building user-mode components with DDK tools (although I find the concept fascinating :-P)
Your kernel mode component should be built separately from the user mode components as a matter of good practice.
Vague thoughts
Off the top of my head, and this really speaking from limited experience...there are a lot of subtle differences that can creep up if you try to mix the two together.
Using your own example of __cdecl vs __stdcall; You have two different calling conventions. _cdecl is all kernel stuff and all of the C++ methods are wrapped around in WINAPI (_stdcall) passing conventions and __stdcall will clean do auto stack clean up and expect frame pointers inserted all over the place. And if you by accident use compiler options to trigger a __fastcall, it would be a pain to debug.
You can definitely hack something together, but do you really want to keep track of that in your user-space code and build environment? UGH I say.
Unless you have very specific engineering reasons to mix the two environments, (and no a unified build experience is not a valid reason, because you can get that from a batch file called buildall.bat) I say use the separate toolchains.
it's possible enable/use OpenGL (specific version) in Qt 4 (on Desktop) or I have to use glew, etc?
Rather than Glew you can include gl3.h, it's probably the simplest and most pain free way and works with compatibility mode as well as core. It's also well worth checking out GLXX it's a newer lib written in C++ so its more object orientated and provides handy functions for querying capabilities and so on.
You could look at manually binding just the extensions you need, possibly making your own Qt classes.
Other alternatives are Glee (A bit out of date now, only up to OpenGL 3.0) and gl3w (a script to generate header files for you, but only seems to support OpenGL 3/4 core).
Also if you want a object orientated library for OpenGL itself OGLplus looks good, doesn't do extensions though.
Qt has wrappers for some extentions like QPixelBuffers otherwise you can just use glew to enable the extentions
My way to do that (Windows)... You need www.opengl.org/registry/api/glext.h
I'm using this python script to generate glex.h (p_glext.h) and glex.cpp from glext.h
p_glext.h is copy of glext.h without prototypes.
//glex.h
#ifndef GLEX_H
#define GLEX_H
#include "p_glext.h"
extern void glexInit();
extern PFNGLBLENDCOLORPROC glBlendColor;
extern PFNGLBLENDEQUATIONPROC glBlendEquation;
extern PFNGLDRAWRANGEELEMENTSPROC glDrawRangeElements;
...
//glex.cpp
...
void glexInit() {
glBlendColor = (PFNGLBLENDCOLORPROC)wglGetProcAddress("glBlendColor");
glBlendEquation = (PFNGLBLENDEQUATIONPROC)wglGetProcAddress("glBlendEquation");
glDrawRangeElements = (PFNGLDRAWRANGEELEMENTSPROC)wglGetProcAddress("glDrawRangeElements");
...
}
that's simple enough to me
For example, this simple class:
class Test
{
public:
Test();
int _public;
};
Test::Test()
{
this->_public = 0; // Shows _public in color
_public = 5; // Stay White
}
This seem to work for Cocoa apps, but not on C++.
Just to be a bit clearer from my original post, this DOES compile and run exactly as expected.
The only impact from Cocoa to C++ is the syntax highlighting. I know that this is only a dev "feature" and shouldn't in any case be seen as a "must have" from the compiler it's just that since it's working for Cocoa why not C++ right ? Give developers a nice feature and they'll want instantly even more :)
Is a fix available ?
You are right, in Xcode 3 it doesn't work. Xcode 4 however does fix this, as it uses a much deeper integration of the compiler. It's not out yet (if you have a developer account you can download a preview), but it will probably be released soon, patience ;)