C# API. The ability to use native PTMC controls in plug-ins
It'll allow user's plug-ins to be more integrated and not look third partyish.
- Bogdan Alexey 1
- Serge Lendich 1
- PTMC team 1
- Irina Ivanova 1
- Cerny Roman 1
- Paul Jeffrey 1
- kaspo999 1
-
Williams Chris 15.07.2016
Thanks Bogdan Alexey for always trying to raise the bar for providing nice plugins that effortlessly integrate into the platform. This is also a great way for passionate programmers or people that just want to learn to assist the PFSoft team with the creation of plugins that users requested.
I'm proud to know that I'm not the only one that wants to create plugins that look native. :)
I know that I had requested a lot, around 20 feature requests, but I think it would also be awesome if we, programmers had the options to use the settings dialog box too. To add, maybe the ability for programmers to add their plugin to other menu's outside the tools menu. Or the ability for a programmer to disabled native panel with code and replace it something that was created by the user.
For instance, I believe that when the user is modifying the TP and SL, a static price is so much easier to work with. So, a programmer could, in this case, create a panel that would allow the modification of TP and SL with a static, order's open price, and disabled the native control, since this panel is just a modification of that panel.
Or how about a programmer that just wants to modify the table alerts so that it can interact with chart objects. With the features that I just mentioned, a programmer could create a panel similar to table alerts, but allows the user to set up an alert when two moving averages crosses. Since this panel supports the things that the native one did and some more, it would be great if the programmer could just disabled it.
These are not a big deal, but I just think it would allow for a cleaner integration.
I'm really proud at how the apps look so far, and while third-party apps are great, they are even better when they can look native and can be used like they are native.
My Android, for instance, doesn't support the ability for the user to look at previous calls duration. You have to get a third-party app. I feel that this information should be located in the call history area, but because of the limitation, I'm assuming, I don't think the programmer had the ability to put it where it should be at or where Android would've put it.
So in closing, I love what I see and providing the users with more flexibility will always be good. I don't feel like we need some of the things that I mentioned, but I just wanted to give out ideas.