Windows Keyboard Input - GLFW | Win32 - winapi

I'm working on a Game Engine and It Currently Supports OpenGL and DirectX11. I've Abstracted my Code in Such a way that for OpenGL, a GLFW window Opens and for DirectX11, a Win32 window opens. Now I'm working on keyboard and Mouse Inputs but the virtual KeyCodes for GLFW and Win32 are both different. Is there a way to kinda make this work by maybe converting GLFW into win32 or vice versa? or maybe through some other way? (if yes then How?).
Also I know I could Use Win32 for OpenGL but it would be nice if I could Use GLFW.

Related

Migrate a Window special tool to macOS, this tool can modify the attributes of other application

I have a Windows tool, it allows we move cursor, click on any third-party window on the desktop to get their related window handle, then we can use those handles to change the attribute of the third-party window such as alpha, WS_VISIBLE, cloak etc of the selected window, is it possible to implement those features in macOS?
The Windows APIs used: WindowFromPoint, SetCapture, GetCapture, SetWindowLong, DwmSetWindowAttribute, ModifyWindow, FindWindow etc,
Is there any mapped macOS APIs for those purposes?
I planned to use Swift and Objective-C, but not sure if it is possible or not
No code yet, just for investigation
not yet
Not possible to port all those features, the closest example will be SonOfGrab

Does Qt4 implement drag and drop with window icons?

Several windows in OS X have drag-and-droppable window icons (e.g. Terminal, Keynote, Finder). Can Qt4 window icons be set up for drag and drop? I can't figure out whether clicking on the window icon triggers any event.
As this feature is specific to only one platform it may not directly available in Qt. Probably you will have to use Cocoa API to handle such events. You can get native window handle:
WId QWidget::winId () const Returns the window system identifier of
the widget.
Portable in principle, but if you use it you are probably about to do
something non-portable. Be careful.
If a widget is non-native (alien) and winId() is invoked on it, that
widget will be provided a native handle.
On Mac OS X, the type returned depends on which framework Qt was
linked against. If Qt is using Carbon, the {WId} is actually an
HIViewRef. If Qt is using Cocoa, {WId} is a pointer to an NSView.
With such handle you probably will be able to handle "window icon drag" with native (not portable!) Mac OS X code

Desktop app noob question: best cross-platform library that can listen for window-change events (focus, lose focus, etc)?

I've only ever done server, web, and database programming, never any desktop programming. I now want to learn and have a small project I want to attempt, but am not sure which library/framework to use.
I'd like to create a small cross-platform app that runs in the system tray (and whatever the OSX equivalent is), and listens for changes to windows on the Desktop. Specifically:
Windows XP, Vista, 7, Gnome, KDE, OSX. BSD, Android, and/or iOS would be nice too but not required.
Listens for when any window gains focus, loses focus, is opened or closed, or if the window title changes (for example when switching tabs in a tabbed browser). Any other information it can scrape from the window would be useful as well.
Can store these events, preferably in an embedded database like SQLLite.
The lighter-weight the better.
Includes an options GUI accessible via a right-click menu from the system-tray icon.
Preferably FOSS, but if you know any non-FOSS please list too.
Is there a single library or framework that can do all that across multiple platforms? QT? Python? Java? Something else? TIA.
Almost any GUI framework can easily let you know when your own application gains or loses focus (or the other operations you mention). However, listening for these events for other arbitrary applications is definitely platform-specific and may or may not even be possible.
One framework for doing this on Windows is the CBT callback hook. See the question CBT Hook not working in Windows Vista for information about possible limitations on using this technique.

Can I use the Cocoa-touch onscreen keyboard in a regular Cocoa application?

I currently have a program written in Cocoa and I would like it to have an onscreen keyboard as I am thinking of using a touch-screen monitor and would like to not have a keyboard for this particular piece of software.
I know there is an onscreen keyboard in Cocoa-touch, but as far as I am aware, that can only be used on the iPhone, iTouch and iPad.
Is there anyway I can use it in a regular Cocoa application?
Thanks
UIKit isn't part of Mac OS X, unfortunately, so you can't use anything from it. There is an onscreen keyboard that you can enable in the system's Language & Text preference pane, but I don't know how you'd do it programmatically. If this is a major requirement for your system, though, it would probably be better to roll your own. OS X is not really designed for touchscreens and has just recently gotten the most rudimentary support for touch-y interaction (thanks to the Magic Mouse and the MacBooks' trackpad).
Unfortunately, the on-screen keyboard is part of UIKit, which is only available on iOS. The only (hacky) option that I'm aware of would be to run your app in the iPad simulator. Not ideal, for sure and I'm not sure how the simulator handles a multi-touch capable display.

How does edit.exe work?

There is an exe in system32 called edit.com . It is an old text editor. I'm wondering how they made a console app have a gui, and work with the mouse? Thanks
There are no shortcuts.The mouse had to be interfaced with through assembly code.You would call interrupt 33 to have access to several functions like reading the mouse motion counters and button states. Then you'd read the CPU registers to get those numbers. From there on you could do everything else in C, including the GUI-like interface. There's no shortcut to that either - it must be manually done, each individual square has to be painted the correct color.
edit.com is REALLY old. It was written before the Windows GUI was really popular. They probably use special DOS functions to create the graphics and recognize the mouse.
Well prior to Windows 3.1 there used to be an operating system call DOS and I believe the mouse thing came with DOS 5.0 or DOS 4.0.
Your best bet for adding mouse and color support to a console is to use some kind of TextArea control and make your own console instead of using the DOS console. You could also look into ncurses for Windows but I don't recommend it. If you just want color you could also look at this tutorial.

Resources