Using Git when programming add-in

For questions regarding programming in the EViews programming language.

Moderators: EViews Gareth, EViews Jason, EViews Moderator, EViews Matt

CrisisStudent
Posts: 48
Joined: Mon Nov 16, 2020 10:52 am

Using Git when programming add-in

Postby CrisisStudent » Wed Dec 22, 2021 6:24 am

Hi all,

I have a question about working with Git in Eviews. Specifically, when programming add-ins I run into an issue that add-in is registered in Eviews, i.e. Eviews refers to a file with particular path. This becomes a problem when I would like to work on version of the add-in file in my own repository, because the add-in call will refer to the registered path. Am I missing something? Can I set up the workflow somehow not to run into this problem?

Thanks!
CrisisStudent
Last edited by CrisisStudent on Thu Dec 23, 2021 1:53 am, edited 2 times in total.

EViews Gareth
Fe ddaethom, fe welon, fe amcangyfrifon
Posts: 13294
Joined: Tue Sep 16, 2008 5:38 pm

Re: Using Git when programming with add-in

Postby EViews Gareth » Wed Dec 22, 2021 9:41 am

I'm not sure I follow the issue.
Follow us on Twitter @IHSEViews

CrisisStudent
Posts: 48
Joined: Mon Nov 16, 2020 10:52 am

Re: Using Git when programming add-in

Postby CrisisStudent » Thu Jan 06, 2022 9:43 am

I had some more time to think about this and realized the specific issue that I am facing is mostly related to my company's use of shared drives - we have a central location for add-in paths which is located on shared drives - and so the problem is more about the conflict between using shared drives and using Git. So feel free to delete this post.

That said, in essence the issue is that Eviews add-ins are registered with given fixed file path, so that one cannot have two versions of add-in files, one for development and one official - the Eviews add-in can refer either to one or the other.

EViews Matt
EViews Developer
Posts: 557
Joined: Thu Apr 25, 2013 7:48 pm

Re: Using Git when programming add-in

Postby EViews Matt » Thu Jan 06, 2022 5:59 pm

A quick note, addin registration is available programmatically. You could for example, write your own addin that switched the registration of other addins between their official and development versions, or even use a git hook to trigger the switch.

CrisisStudent
Posts: 48
Joined: Mon Nov 16, 2020 10:52 am

Re: Using Git when programming add-in

Postby CrisisStudent » Mon Jan 17, 2022 10:38 am

Ah, that's a smart idea! (Not sure why I am surprised). Especially since the addin command now includes the nowarn option, which I did not realize.

If you have example of Git hook you have in mind, feel free to share, it goes outside the scope of my (very limited) Git knowledge.

EViews Matt
EViews Developer
Posts: 557
Joined: Thu Apr 25, 2013 7:48 pm

Re: Using Git when programming add-in

Postby EViews Matt » Wed Jan 19, 2022 3:14 pm

This all depends greatly on your workflow and Git setup, but for this example suppose we have a local Git repository with the "master"/"main" branch and a "dev" branch. We want different versions of an addin registered in EViews depending on which branch is currently active, and we can use Git hooks to automatically switch that registration whenever we switch between branches. And just to make our lives more interesting, I'll use COM automation to interact with EViews, which will let us change the addin registration for a running instance of EViews (so we don't need to restart EViews).

I assume the Git command-line tools are available; I constructed this example for a "Git for Windows" installation. From the Git repository root directory, in subdirectory ".git\hooks\", we can create a script that will trigger whenever we checkout a branch. Since I've injected COM into this example, I'll actually use a pair of scripts. Git will call the first script, which will call the second script, which will interact with EViews to register the desired addin. The first script will determine which version of the addin we want to register based on whether we've switched to the "dev" branch or not. Mechanically, this first script is just picking a command that will be executed in EViews. The real payload of the script are the "addin(proc=foo) dev_version.prg" and "addin(proc=foo) prod_version.prg" strings, which naturally would need to be altered to reflect the true details of the addin.

.git\hooks\post-checkout

Code: Select all

#!/bin/bash

branchName=$(git branch --show-current)

if [ $3 = '1' ]; then
   if [ $branchName = 'dev' ]; then
      cmd="addin(proc=foo) dev_version.prg"
   else
      cmd="addin(proc=foo) prod_version.prg"
   fi
   cscript.exe //NoLogo $(dirname "$0")/post-checkout.vbs "$cmd"
fi

The second script takes care of the details of executing the chosen command, i.e., registering an addin, in EViews via COM.

.git\hooks\post-checkout.vbs

Code: Select all

doExit = False
Set mgr = CreateObject("EViews.Manager")
Set app = mgr.GetApplication(2)
If app Is Nothing Then
        Set app = mgr.GetApplication(0)
        doExit = True
End If

app.Run(WScript.Arguments.Item(0))

If doExit Then
        app.Run("exit")
End If

The net result of these example scripts is to modify a fictitious global addin named "foo". If we switch to the "dev" branch then the addin is associated with the dev_version.prg program, but if we switch to any other branch then the addin is associated with the prod_version.prg program.


Return to “Programming”

Who is online

Users browsing this forum: Google [Bot] and 15 guests