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
Using Git when programming add-in
Moderators: EViews Gareth, EViews Jason, EViews Moderator, EViews Matt
-
- Posts: 48
- Joined: Mon Nov 16, 2020 10:52 am
Using Git when programming add-in
Last edited by CrisisStudent on Thu Dec 23, 2021 1:53 am, edited 2 times in total.
-
- Fe ddaethom, fe welon, fe amcangyfrifon
- Posts: 13319
- Joined: Tue Sep 16, 2008 5:38 pm
Re: Using Git when programming with add-in
I'm not sure I follow the issue.
Follow us on Twitter @IHSEViews
-
- Posts: 48
- Joined: Mon Nov 16, 2020 10:52 am
Re: Using Git when programming add-in
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.
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 Developer
- Posts: 563
- Joined: Thu Apr 25, 2013 7:48 pm
Re: Using Git when programming add-in
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.
-
- Posts: 48
- Joined: Mon Nov 16, 2020 10:52 am
Re: Using Git when programming add-in
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.
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 Developer
- Posts: 563
- Joined: Thu Apr 25, 2013 7:48 pm
Re: Using Git when programming add-in
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
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
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.
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.
Who is online
Users browsing this forum: Majestic-12 [Bot] and 53 guests