SoftTree Technologies SoftTree Technologies
Technical Support Forums
RegisterSearchFAQMemberlistUsergroupsLog in
Sublime Text 3 and SQL Assistant

 
Reply to topic    SoftTree Technologies Forum Index » SQL Assistant View previous topic
View next topic
Sublime Text 3 and SQL Assistant
Author Message
amasanchez



Joined: 20 Dec 2011
Posts: 4

Post Sublime Text 3 and SQL Assistant Reply with quote
I currently use sublime text 3 text editor for much of my dev work, but I am forced to step out of it to use SQL assistant. Is there any way that Sublime Text can work with SQL Assistant. I tried capturing the target window class (PX_WINDOW_CLASS) but it still doesn't seem to work. This version seems to be much different than the sublime text of the past, so i was wondering if using SQL Assistant is now an option.

Thanks for any help on this.
Wed Mar 05, 2014 1:19 pm View user's profile Send private message
SysOp
Site Admin


Joined: 26 Nov 2006
Posts: 6509

Post Reply with quote
Hi

I installed a copy of sublime and also couldn't get it to work SQL Assistant. The editor is very nice but totally custom and doesn't seem to support standard event and messages expected in Windows editor control.

What I found is that in Sublime you can define a key map to create a key that would invoke for SQL files an external editor. for that purpose you can use the SQL Editor bundled with SQL Assistance and make them work sort of "in tandem."
Thu Mar 06, 2014 1:31 am View user's profile Send private message
gemisigo



Joined: 11 Mar 2010
Posts: 1401

Post Reply with quote
Is support for standard event and messages going to be a requirement for an editor to be SA compatible in future versions of SA (eg. oncoming v8) as well? Too bad these two gems cannot get along :( Furthermore, it restricts SA to Windows platform which is also a pity.
Sat Feb 20, 2016 8:37 pm View user's profile Send private message
SysOp
Site Admin


Joined: 26 Nov 2006
Posts: 6509

Post Reply with quote
It's required for editors for which there are no native add-ons / plug-in. That's how they communicate. SQL Assistant them standard messages (like EM_GETLINE, EM_SETSE, and a bunch of others) to the editor window and expects standard message processing and responses. Otherwise it simply won't work. For editors used in SSMS, VS, DB Tools, Delphi, Eclipse, it installs specially developed add-ons (or plug-ins), which are used for the inter-process communications, they internally execute editor's API methods, without using inter-process messaging. the add-ons can run standalone within the editor's IDE, but if SQL Assistant app is running in the system tray, they can also communicate with it for enhanced user's experience, to show notification messages, to provide callback functions for changes in the global settings, and so on...
Sun Feb 21, 2016 1:16 am View user's profile Send private message
gemisigo



Joined: 11 Mar 2010
Posts: 1401

Post Reply with quote
Does that mean that if I succeed in asking, pleading, begging, motivating, paying, bribing, forcing, blackmailing or simply threatening someone into making an add-on/plugin that could connect SA with Sublime Text 2/3, these two could work together?
Sun Feb 21, 2016 10:17 am View user's profile Send private message
SysOp
Site Admin


Joined: 26 Nov 2006
Posts: 6509

Post Reply with quote
Certainly. Why not? There are two ways to integrate SA with the target editor if the editor doesn't handle standard messages. Use the available SA API to invoke SA functions directly from the editor or the add-on (see http://www.softtreetech.com/sqlassist/api.htm, the linked examples are somewhat outdated, but the concept is current) or make the add-on in a way it implements the "standard" set of message to allow SA to work with the editor as if those standard messages were supported out of the box, kind of create a bridge. The first method provides the most flexibility, but its subject to API licencing fees. It offers full freedom to where and how to use the available SA functions, and to a certain degree allows customizing and enhancing them as desired. The second method is less flexible, but one doesn't need to license the API.
Sun Feb 21, 2016 10:48 am View user's profile Send private message
SysOp
Site Admin


Joined: 26 Nov 2006
Posts: 6509

Post Reply with quote
I failed to mention one other important difference. With the API, SA functions are part of the application, one doesn't need to run SA application separatelly. In the second case, SA needs to be run as a standalone system tray application.
Sun Feb 21, 2016 10:53 am View user's profile Send private message
gemisigo



Joined: 11 Mar 2010
Posts: 1401

Post Reply with quote
Nice. Any tutorials on how one creates an add-on? :)
Sun Feb 21, 2016 11:09 am View user's profile Send private message
SysOp
Site Admin


Joined: 26 Nov 2006
Posts: 6509

Post Reply with quote
It's pretty much target editor specific. For example, if you choose to create an add-on for VS, you can find tutorial on Microsoft's MSDN site. For SSMS, Microsoft doesn't document the internal APIs, but there several blogs on the Internet describing in detail how various SSMS add-on developers did it using trial an error method.

If you choose to go with SA API method, please download the samples I referenced in an earlier post; the sample code seems to be fairly simple and I hope easily readable. If you have any questions, please feel free to contact our support group.

If you choose the other method, then you need to implement support for a set of standard EM_ messages, the magic will happen after that. Again, if you need a list of required EM_ messages, please contact our support and they should provide you with that.
Sun Feb 21, 2016 12:40 pm View user's profile Send private message
gemisigo



Joined: 11 Mar 2010
Posts: 1401

Post Reply with quote
I must admit, I'm a bit confused. I'm not an application developer and I'm not sure I understand everything. Let me ask a few questions and try to describe how I see it before turning to support so that you can confirm or correct me if I'm wrong.

There are two methods:
a. Using the SA API (which is subject to API licensing fees)
b. Creating add-on for a specific editor

a. is more flexible and needs no SA installed or running but it would require modifying the app itself to use the API.

b. on the other hand needs SA installed AND running. It would also require writing the add-on that would somehow implement the missing set of standard EM_ messages that the editor lacks and act on editors behalf in case the said messages are sent. The implemented messages would act as sort of an API towards SA and it should translate the incoming messages into something that the editor would understand (probably using its internal API such as was the case with SSMS) so that it could mimic the behavior of SA Editor.

a. would be rather large task even if I could obtain a copy of the source for the editor (and let's forget about my meager capabilities as coder for a second).

b. demands a slightly smaller effort and depends mostly on the editor, its API and the person trying to "invade" it, with SA not needing to know anything about it.

Am I correct?
Sun Feb 21, 2016 1:24 pm View user's profile Send private message
SysOp
Site Admin


Joined: 26 Nov 2006
Posts: 6509

Post Reply with quote
You are correct. But I would not agree completely with the last "b" statement because it really depends on the editor's implementation.

Quote:
b. demands a slightly smaller effort and depends mostly on the editor, its API and the person trying to "invade" it


First of all you would need to know how the editor handles various operations internally. Say, how to convert EM_SETSEL standard message to the editor's set of instructions or equivalent non-standard messages implemented in the editor, or alternatively what functions in the editor's API to call (if they are available) to achieve the required text selection. The overall effort to build a full bridge might be very significant. If you don't have access to the editor's source code or don't have a good knowledge of its published API, if there is any, it might be nearly impossible for you to develop a bridge.

As for
Quote:
a. ... would require modifying the app itself to use the API.

that depends too. If the target editor provides extensible you can add new functions without changing the original code. Here is a hypothetical example, if you want to add SQL code formatting function to SSMS, rather then using SA's provided add-on for SSMS, you can develop your own add-on for SSMS that can add new "Format Code..." menu command to the editor's right-click menu. When that menu command is activated, your add-on can call SA's API passing the text to format, and then replace the text in SSMS with the formatted version. As you can see, in this case SA doesn't interact with the editor directly, you use its functions to process text. So to speak, you don't need to modify original code of SSMS in this case, you only need to develop your own add-on and register it with SSMS.

Hope this helps.
Sun Feb 21, 2016 3:57 pm View user's profile Send private message
gemisigo



Joined: 11 Mar 2010
Posts: 1401

Post Reply with quote
It does, thank you very much for the info. I guess I'm going to adjourn it until I can learn a bit about the things you talked.
Tue Feb 23, 2016 7:15 pm View user's profile Send private message
Display posts from previous:    
Reply to topic    SoftTree Technologies Forum Index » SQL Assistant All times are GMT - 4 Hours
Page 1 of 1

 
Jump to: 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

 

Powered by phpBB © 2001, 2005 phpBB Group
Design by Freestyle XL / Flowers Online.