SRP Editor Events

Michael

I have a client that is using the SRP Editor (or some of their developers are). I've not used it much myself, so my knowledge is somewhat limited. We have written a wrapper around the Repository function that will intercept Lock calls for OIWIN and STPROC modules; we are trying to provide an easier way of facilitating checkin/checkout functions. This works great when using either the original Editor or the Editor++; but the SRP Editor seems to bypass the Repository altogether, at least for locking purposes.

Is there any way that the SRP Editor interfaces with the Repository? If I can't trap Repository calls, is there another function that is used that I can access and/or "wrap"?

Thanks,

Michael Matthews
paladinn@verizon.net

KevinFournier

The SRP Editor supports the ability to open inherited stored procedures and save/compile them within their inherited application. The Repository method does not allow this, so we had to circumvent it in order to achieve this feature.

I suppose you are intercepting Repository calls using your own wrapper. One possibility is that the SRP Editor provide it's own hook that not only allows you to determine when entities are being opened, saved, compiled, or deleted, but also gives the developer the opportunity to prevent such things from happening.

Thoughts?

Michael

Hi Kevin,

I've indeed written a wrapper around the Repository functions. I have a good generic procedure to lock the STPROC or OIWIN records, allowing a developer to view if s/he can't check the module out. But since the SRP Editor bypasses Repository, the approach won't work within the SRP Editor.

Is there currently a "hook" like what you describe? What sort of record locking mechanism is currently being used in the editor?

Thanks,

Michael

KevinFournier

There is no "hook" yet. Rather, I'm getting a feel for what could work for you. An SRP Editor specific hook means less work for us since the only other solution I can think of involves a configuration setting that effectively disables the support for inherited entities and forces the SRP Editor to only use the Repository method.

For locking, I do use the Repository "ACCESS" function to determine if the entity is opened normally or in read-only mode.

Michael

Soo.. you're saying that the SRP Editor currently utilizes the ACCESS function? If so, that might work for me.

I'd just need to look at the ACCESS function instead of the LOCK function.

Cool!

Michael

Hi Kevin,

I tried the wrapper around Repository just looking at the Access function.. it didn't work for Any of the tools (Editor, Editor++, SRP Editor or Form Designer) . I must be doing something wrong.

Can you please contact me and give me some words of wisdom?

Thanks,

Michael Matthews
paladinn@verizon.net

KevinFournier

I'm not sure why it isn't working for you. Here is the snippet of code that I use.
// Get the procedure's data (from Repository whenever possible) DataRead = 0 Data = Repository("ACCESS", ID) If Get_Status(ErrCode) then Read Data from hProcs, ProcKey then DataRead = 1 end else Swap CRLF$ with @FM in Data DataRead = 1 end
Note how I try the repository, and if it fails, I try to load the record manually. This is another example of why wrapping just the Repository doesn't work with the SRP Editor.

SRPSupport

Soo.. you are calling it directly.. and there's no way to intercept the call from the editor?

That's making version control and collaborative development Very difficult!

DonBakke

Michael,

There is always another way assuming one is willing to pay for it. :-)

Honestly, the real reason version control is difficult in OI is because it stores everything in the database. While that has its advantages, it also does not play nice with standard version control tools.

DonBakke

Soo.. you are calling it directly.. and there's no way to intercept the call from the editor?

Michael, I wanted to follow up with you on this comment. How else would we be calling the Repository function if not directly? I thought that was the whole point of your question since you have your own wrapper. What am I missing here?

Michael

Hi Don,

I wrote my wrapper around the Repository function to intercept a particular function. Originally it was the Lock function; then, I changed it to catch the Access function based on Kevin's recommendation. It turns out the Editor doesn't use the Respository Access function either, as the wrapper didn't fire for either function.

Kevin's last posts show code that actually forces a call to the Repository Access function; and he goes on to say that wrapping Repository won't work within the SRP Editor.

The OI Editor, Editor++ and Form Designer all use the Repository Lock function, so it was easy to intercept with the wrapper. I just need to do something equivalent from the SRP Editor.

Michael

KevinFournier

Michael,

Indeed, I don't use the Repository LOCK method. I just check for standard record locks.

The problem is that the philosophy behind the SRP Editor is at odds with a version control philosophy. As developers, we didn't like being hindered from being productive (such as not being allowed to edit and compile inherited stored procedures), so we opened things up for convenience. The downside is that such openness runs contrary to your needs.

So, now we're in the interesting position of finding a way to allow you to lock things down while preserving the openness that our clients (and we) have come to enjoy.

Michael

So it sounds like I need to do both the Repository wrapper and an MFS. I tried doing an MFS alone, and the Editors and Form Designer bypass any MFS with Repository calls.

Unless the SRP gurus have another solution?

DonBakke

Michael,

The only other solution is one that does not exist yet. I do not know if you have been following the other thread originated by David Goddard, but ironically he has been asking for very similar features at the same time you began asking for them.

The only way we think we can provide everyone the best of all worlds is to provide support for custom hooks. This would provide the coder a way to identify the name of a custom stored procedure that the SRP Editor will call whenever a major C.R.U.D. action takes place. At first it might simply support notifications so you can track this but later on we might enhance it to enable more interactive control.

Of course, any solution requires time...and time equals money. Additionally, we have a slate of issues that we are behind on with regard to the SRP Editor, some of these are midstream in completion.

So the bottom line is, "How bad do you want this?" We will always rearrange priorities if a customer makes a special request and wants to help cover the costs. Otherwise, we have to fit this in when it is feasible.

daveh

I'm "expanding" this thread.

This year Don posted a blog entry about "Hooking in BASIC+". I need the means of determining the Table and Key as edited in the SRP Editor. This is to create backup and logs on programming activity. So, I created a hook for it.

I copied the SYSOBJ $SRP_EDITOR_EVENTS to $SRP_EDITOR_EVENTS_ORIG and created my own SRP_EDITOR_EVENTS as a "hook". I guessed there would be up to ten parameters and it was a function.
Watching this in debug is very slow, so I just wrote a row into SYSLISTS and exported the parameter values. This is to look for the Table, Key, and figure out when a Save or Compile is performed.

Nothing in my captured parameters contains a Table or Key or operation so I ask SRP, "Do you keep this in some labeled common"? If so, can I have that documented? Or, how can I accomplish my goal?

Thanks,
Dave

DonBakke

Hi Dave,

First, the original article I wrote follows a good practice but it does require a bit of housekeeping by way of backing up the original stored procedure. I much prefer the technique that I documented in my follow-up article called Hooking in BASIC+ – Using Different Bait. This is less intrusive and allows the original stored procedure to remain intact. Regardless of the approach you take, the follow comments will apply.

Rather than simply documenting what may or may not be proprietary information, I'm going to approach this as if I was trying to get this information on my own and as if I did not have the benefit of access to the SRP Editor source code.

I created my hook shell. Rather than guessing the number of parameters, I used the SRP Editor itself to tell me. Just enter any stored procedure, an open parenthesis, and press Ctrl+T. You'll get a tooltip of the official parameters. I always do this to avoid accidentally having too few or too many parameters when the hook is activated.

Like you, I discovered that hooking the commuter in debug mode is tough. Not only do you get a billion events, but many of them are labeled in a cryptic numeric scheme. However, I figured that the process of saving or compiling a stored procedure must go through a control containing the name Save and/or Compile. So, I added this to my hook procedure:

If IndexC(CtrlEntId, 'COMPILE', 1) then Debug

Voila...that struck gold the first time. Now when I press F9, use the menu, or click the toolbar button, I am able to trap the compile process. However, as you noted, there is nothing in this event handler that identifies the name of the stored procedure. The logical reason for this is because the request to compile is just now being invoked, the code within the commuter will resolve the important information. The question is how?

Well, this is OpenInsight so we can probably make some intelligent guesses. We know how OpenInsight MDI frames work. The MDI Child that is active is certainly going to be the form containing the source we are compiling. So let's just get the active window and its caption like this:

If IndexC(CtrlEntID, 'COMPILE', 1) then debug MDIActive = Get_Property(@Window, 'MDIACTIVE') Text = Get_Property(MDIActive, 'TEXT') end

Tada! The Text variable now contains the name of the stored procedure you are trying to compile. If you want to trap other entities that are being updated in the SRP Editor, such as records, then change the word "COMPILE" to "SAVE". The caption of the MDI child always contains the relevant information you need.