Position indicator (willing to help)

[FatCat0]

I'd like to be able to generate a rectangular area and have another program tell NohBoard where to draw a dot within it. I think this could be accomplished in a manner similar to the mouse movement indicator's behavior. I'm willing to write this whole feature (even if just for my own personal build), but answering either of the following (or pointing me in the right direction) would speed up the process a lot: 1) Can I make the companion program generate Windows events to pass data to NohBoard (since I think that's how it gets keypresses)? If so, any advice on doing so in a way that NohBoard will be able to receive and handle them nicely? 2) Besides Visual Studio, is there anything I need (/to know) to build this into a working exe file? I've worked with C# a fair bit but always in conjunction with Unity so I have never had to worry about actually deploying code to an exe. Even just trying to build the solution I run into a couple of errors ("Version" not existing within the namespace of MainForm.cs and the gotri.exe calls exiting with code 2), and you do reference things like "Designer" all over the place. I don't even know what that is so that makes me think I probably don't have it available to work with.

Really, even if you can just help me with 2 so I can get to the point of being able to tinker with the software I can probably figure things out from there.

[ThoNohT]

1. I am not sure exactly if this is possible. I can tell you how NohBoard handles keyboard and mouse events:? It hooks into the low-level keyboard/mouse hook. This is just part of the windows message loop. I have no idea however if it is possible to define custom hooks with custom messages. Should you want to go down this path, make sure to check MSDN: Inter Process Communication for other possible methods.

2. No, Visual Studio (2017) should be the only thing you need to build NohBoard. These designer files are just part of generated files when you create a form inside Visual Studio. If your version can't handle it, then I'm not sure if you have the right version. It should work fine with VS2017 Community for example. gotri.exe is a file that generates Version.cs from Version.cs.template. So if the call to gotri.exe fails, then it's to be expected that Version.cs doesn't exist. A possible cause might be that you've downloaded the source as a ZIP rather than cloning it with Git. You really need a Git checkout for it to work.

That leaves me with some extra questions.

3. What is it that you are trying to achieve exactly? What is the meaning of this moving dot?

4. Can't NohBoard determine this position by itself, without the need for an external program? Because if this program is needed, then it feels like distributing NohBoard without it would result in an incomplete package, which I don't really like. If it's a useful extra element that works standalone, then I really wouldn't mind adding it, but if it really needs extra software then I feel like I would leave it in your own custom build rather than including it.

5. If NohBoard can't determine the position itself, can't your extra program just do the drawing? Using a bit of GDI+ code to draw things isn't that difficult. It might even be easier than trying to get Inter Process Communication working properly.

[FatCat0]

1: Thanks for the suggestion

2: Either of these might be the reason. I still use VS 2015 since it has never failed me before now. I'll update and try to compile again next time. I also did download the project instead of cloning it (I didn't realize there was a difference : X)

3: I'm trying to add a motion sensor-based mouse tracker to the layout. Some people do mouse cams (I both can't and don't want to), this is supposed to achieve a similar effect via the dot moving around the mouse pad area. Ideally it will actually be an arrow to include the mouse orientation

4: Due to 3, and the fact that motion sensing is not really a standardized feature, I don't ever see generating the position being a part of NohBoard. I'm writing a standalone program to take the input from an arduino that the motion capture is attached to and interpret that into absolute position. I don't know if there are other good uses for such a feature, and I know my particular use is very niche. The only thing that I can think of that's sort of related is if someone wanted to do a similar thing with just the mouse input. Instead of having the direction/magnitude display as is there now, one could display a moving dot or even traced line. This would have to be recentered periodically, obviously. I don't know if there's a desire to have a feature like this though, which is why I have no issue writing this mod myself.

5: This might be the way to go. It would be nice to have everything in one package (since I plan on using this in conjunction with NohBoard's current functionality), and getting all of the elements correctly and consistently aligned would be a matter of setting up the NohBoard layout once, but yeah, maybe it's not worth the setting up effort.

Thank you for your time ThoNohT, and the quick reply!

[ThoNohT]

I have another idea. This will require some work on my end. But why not make it in the form of a plugin? NohBoard currently has no plugin support. But a typical plugin could be a new ElementDefinition. I can't tell you the specifics about it from the top of my head. But it would need several functions for starters:

• Id -> For serialization
• Render()

It has to have a data contract, and all of its relevant properties should be data members, so the element can be serialized into a .kb file.

Then if you want to support the Edit Mode that I am currently in the process of creating. It would need the following other functions:

• RenderEditing() -> Simplified version of render while the element is being manipulated.
• RenderHighlight() -> An overlay rendered when the mouse is over the element.
• RenderSelected() -> An overlay rendered when the element is selected.
• bool StartManipulating(TPoint Location, bool altDown) -> Asks the element if it can be manipulated by dragging the mouse from the specified point, should set its manipulation type internally.
• ElementDefinition Manipulate(Size diff) -> Creates a new version of the element with the currently active manipulation applied with supplied distance.
• ElemetnDefinition Clone()

It would take quite some work I think to get NohBoard ready to accept plugins, because the external elements would probably differ in several ways from the current ElementDefinitions. And how to handle styles for these things, I cannot begin to think about :P

[FatCat0]

Do you have any tips on things to (not) do to minimize incompatibility of elements? Again, no experience with them, but considering the notes in your code (about some segments being auto-generated and not to touch them) it seems like at least some of this setup is not directly accessible. And by styles, are you referring to the sets of base images ala the different keyboard layouts available right now? Or style info generated by VS?

[ThoNohT]

Generated code is exactly that: generated by Visual Studio when you design a form using the form designer. If you navigate through the code with Visual Studio, you should not easily land on such code, as it hides it from you (though it is possible to see it naturally).

If you look through my code setup, you can find that keyboards are displayed by two types of ..things:

• Element Definitions (Lookie here)
• Element Styles (Lookie here)

The upper level is a Keyboard Definition, which contains:

• Its own style
• Default styles for all types of elements
• A list of all element definitions
• A list of element styles for specific element definitions, where they are defined.

Using all of this information, NohBoard is able to display the keyboard.

Now how would a plugin work, from my current point of view (nothing is implemented yet, and I only gave it some real quick thoughts)? The keyboard contains a list of ElementDefinitions, which is the base class of all types of elements that can be added to a keyboard. A plugin would implement a new implementation of ElementDefinition, with the methods I mentioned above implemented. When I implement plugins for NohBoard, it will then just scan for dlls in some defined folder. From each plugin, all types that are a subclass of ElementDefinition are looked up, and the methods above are used to display these elements in a keyboard, serialize them in the .kb files, and edit them.

Now problem 1 is: ElementDefinition contains a lot of extra stuff that is not relevant for elements defined in a plugin, so I would have to change some stuff so a suitable base-class is provided that only requires the plugin creator to implement the absolutely necessary methods.

Problem 2 is: Styles: Styles are defined in a file different from the keyboard, this allows people to create multiple styles for a single keyboard. In my code I know which Style types belong to which Element types, and can apply them easily. I don't have this knowledge when loading a plugin. So I need to find a way to let the plugin determine which style class applies to which element definition class. And naturally, these styles need to be serializable, implement the base class ElementStyle, etc, etc.

Problem 3: I created special forms (windows) for editing the styles of elements/the keyboard. And I am currently creating the forms for editing the properties of elements/the keyboard. I can't create this for elements from plugins. So I would probably have to get a pointer to a function that shows the element properties window, the element style form (both for a default per keyboard, and for specific instances of that element, should there be multiple). And all of these forms would have to be implemented in the plugin itself.

Note: none of these problems make it impossible to do this. They are just points that will need to be tackled if I were to support this. And it will probably take quite a while to get this implemented. So if you are in a hurry getting this done, then it may be best to just make your own fork which has the element added. And eventually, it can then hopefully pretty easily be rewritten to a plugin.

[FatCat0]

This definitely will exist as a standalone thing before I even consider making it compatible with NB. I just got the sensors and still have to set up the whole motion sensing thing (and, no small feat, make it work well enough to warrant the trouble of live displaying the data). Thank you for all of the information you've already provided. I'll definitely keep these things in mind while developing on my end. If I get it up and working and interfacing with my own build of NB I'll let you know, and I'll keep an eye out for plugin support.