Greetings,

I'm a long-time programmer (started in 1979 on an Apple II and never looked back). I'm also an avid gamer and have used Steam since it's earliest days. I've used Display Fusion for about a year or more and just picked up Voice Bot. As it's the weekend, and I love programming, I thought I would dig into a little desktop automation for entertainment and productivity reasons.

As I dug into the C#-based API and started writing macros, I realized that I was not getting some of the standard IntelliSense for very basic things like StringBuilder in the provided macro editor. This set me on a course to see if VS13 could be used.I started digging for the DLL that contains the BSF utilities but I could not find it. I started looking at the registry to see where things were stored and found the profiles and (encoded) macros. I looked at discussions on the forums and saw that the company and community are fairly responsive and interested in supporting contributions.

So, I wanted to ask a question to clarify some things I have discovered so far:

First, one of the threads said you simply don't support Visual Studio development (someone asked about using it), but this is a bad scenario for developers interested in contributing. The strongest use case is this:

1) C# programmer developers several macros.
2) Not able to use DRY (Don't Repeat Yourself) principles and put common code into a library, the developer repeats the same functions in all (or at least many) of his/her macros.
3) Since the macros are stored in the registry, this eventually impacts system performance and the experience degrades rapidly.

Instead a better solution is to use a custom library, which I see is supported. Great! But wait! I can't reference the BFS library, so I can't do the most obvious abstracts first (those that are likely to help the community most). By way of example, the first macro I wrote included a method like this:

private static void FocusOn(string match) {
IntPtr handle = BFS.Application.GetMainWindowByFile(match);
if (handle != IntPtr.Zero) {
if (BFS.Window.IsMinimized(handle)) {
BFS.Window.Restore(handle);
}
BFS.Window.Focus(handle);
}
}

This is a function that can be repeated in many, more specific, macros. Cutting and pasting is clearly an option but maintenance would quickly get out of hand, not to mention bloat. The smarter move would be to put this in a DLL and add it to the Display Fusion directory and reference it. In fact, this is a prime candidate for contributing back to the community.

So two things come to mind:

1) Why not support importing the Display Fusion (BFS) reference into Visual Studio project? If I'm mistaken about this, where is the DLL file to import?
2) Why not support the notion of a common macro that can be called by others (or can they). For example, can I write functions in C# class with a name other than DisplayFusionFunction or VoiceBotScript and then reference it in another macro to reduce/eliminate duplication?

The first option is clearly the most desirable (VS support and library referencing)). I'm not clear on why this should be limited as new products might just emerge that would increase sales. The second is a workaround at best and introduces complexity that is probably best left out of the macro editor.

Comments welcome. Please let me know if I am missing something or maybe confirm my assumptions...

Well, my english is not so good. But I must agree with CubicFlash.
I tried to edit my scripts with VS too, without success.
I think for people who know C# a little bit it would be nice to use VS and IntelliSens. And people who don't know C# will have problems with the build in editor, because it's not working for many things.

So, please give us a dll we can work with!

Like CubicFlash, I to am a C# developer, and have successfully incorporated VS 2015 into the build process (primarily for intellisense, and debugging). Currently for the BFS namespace, I emulate and stub any functions that I use from that library with fixtures or approximation code based on the output of the real deal. Code compiles, and can be debugged. I've even added tts and such so the emulation is more complete. I have macroscript templates via VS that make new macroscript development even faster however, DRY is were I aim to be.

I too am looking for the BFS library dll, so that I can build function library dll's that can be referenced by the macroscripts allowing common code to be refactored into said libraries.

As stated, the problem is were is the BFS library so this can be made manifest?

I'm certain that there are functions withing the BFS library that will only work from within the VoiceBot\\displayfusion application, but to build the function libraries, which will also be run from withinVoiceBot\\displayfusion, that is a moot point, it is only required for the references at build time.

It is this ability to code in C# that won over VoiceAttack, because any complex scripting they can do, I can code just as easily in VoiceBot thanks to the use of .Net as the language. And luckily, many of the features they have, VoiceBot also has a counterpart to, however, the scripting side is more powerful in your product. XD

I can do nearly anything that I've tried to code and has worked, to include incorporating DB functionality, and some others , with the only issue being the missing BFS library which would allow crafting proper function libraries (DRY).

Even the registry thing is not an issue, nor the encoding ( as I haven't seen many post anything about it, I hadn't realized that CubicFlash and I had gone on a similar journey with similar outcomes).

Some libraries can be crafted, but can only contain code that doesn't directly tie-in to the BFS functionality, which is what some of the libraries attempt to make common.

Anyway, I love the VoiceBot product, and ask that a reference library be created allowing us to craft function libraries referencing BFS functions as external, so we can code even more love into this construct! ^_^
-----------------

So, it occurred to us that, it was likely, that the lack of an external dll meant that the library code was the executable itself, and that we could use scripting to gaining includes, after a fashion. thus allowing script writers to create common code, and store them in variables in the registry, or as DB records for those that have written DB driven code, and load them into the running script (DRY); only the script-engine need be added to every script intended to share code, and of course, the includes can be different as desired for each script as the developer sees fit.

I have a working prototype (I love VoiceBot!) and while it is part of a cadre of code I've crafted for my Elite Dangerous macro system (yet complete, but getting there) I can share the eval\\includes code once cleaned up for developer consumption with a short example. Developers may assimilate the logic into their constructs as desired, or not... . Also, having discovered the Holy Grail of the proper libraries thing, we discussed above, adding the VoiceBot.exe as a reference will open that pathway to coding goodness, DRY via library, or includes\\eval FTW!

Thanks,

Hack and the World Hacks with you!

End of line. -(Darkstrumn:160115.03)