In a bid to keep a template pure source, with no external DLL’s, if someone were to want a template but it used Powershell to perform some functions, what objections would there be?
In this example, the template alters the line entry to swap the debug clarion runtime in and out of use, easily. Just trying to avoid compiling DLL’s for the template with different versions of Clarion.
I use a regular command prompt, not PowerShell, but ive got a few templates that generate BAT files, and then execute them (with cmd.exe as i recall). Havent had any complaints.
Cmd is more accessible than Powershell, the latter might not be installed, locked down via group policy, but there isnt the functionality in Cmd.
Powershell to add %BIN%\debug
(Get-Content "C:\Clarion11\bin\CLARION110.RED" -Raw) -replace '(\[COPY\].*?\r?\n(?:.*?\r?\n)*?)(\*\.dll\s*=\s*)(?i)(%BIN%\s*;\s*%BIN%\\AddIns\\BackendBindings\\ClarionBinding\\Common\s*;)', '${1}${2}%BIN%\debug;%BIN%;%BIN%\AddIns\BackendBindings\ClarionBinding\Common;' | Set-Content "C:\Clarion11\bin\CLARION110.RED"
Powershell to remove %BIN%\debug
(Get-Content "C:\Clarion11\bin\CLARION110.RED" -Raw) -replace '(\[COPY\].*?\r?\n(?:.*?\r?\n)*?)(\*\.dll\s*=\s*)(?i)(%BIN%\\debug\s*;\s*%BIN%\s*;\s*%BIN%\\AddIns\\BackendBindings\\ClarionBinding\\Common\s*;)', '${1}${2}%BIN%;%BIN%\AddIns\BackendBindings\ClarionBinding\Common;' | Set-Content "C:\Clarion11\bin\CLARION110.RED"
The template puts the local redirection file path & name, if its detected, else the IDE redirection file path & name, if its detected and informs if it cant find either.
Unless I can find a way to do one Clarion.dll for #RunDLL which can be called by the template running on any version of Clarion, it will have to be the powershell route for now.
I agree that CMD (or powershell) is preferable to #RUNDLL (which is a pain to support across multiple clarion versions.)
Perhaps though, given the potential for the Powershell command to fail, there is an alternative approach. Perhaps the template could literally read in the RED file, and edit it (writing it back.) It’s an ASCII file, so that’s do’able.
Perhaps it’s even easier - just run a COPY command to copy the DLL from \BIN\DEBUG after the compile, essentially overriding the automatic copy from \BIN
Indeed, you might even do a simple
#PROJECT('library(c:\clarion\bin\debug\clarun.dll), CopyToOutputDirectory=Always')
which (if done after the built-in one) would override the bin\clarun.dll
(Obviously you’d use a %variable for the clarion part of the path)
#PROJECT('library(' & %somepath & '\bin\debug\clarun.dll), CopyToOutputDirectory=Always')
But maybe this is all a bit bike shedding. Personally I just copy \bin\debug into \bin when I get my Clarion. Then the CLARUN is always the debug version. I find this the most useful because it makes debugging GPF’s (even GPF’s at client sites) trivial.
But this is all specific to your current use case. In terms of the general use case, I (personally) have no objection to a template that used powershell. And I expect that pretty much all developers would have access to it, so I don’t think restrictions would be an issue.
There can be compatibility issues, between different versions of Powershell, depending on what you’re doing. So you’d want to ensure whatever pre-requisites are satisfied before trying to use it. Plus, Powershell 7 is not the same as the Powershell that comes with the OS, etc.
Tried, I think the IDE has it open because the App is open and thus using the RED which prevents it from being #Open’ed by the template, error message thrown, havent used Sysinternals to see what record locks are in place either, but didnt try ,Read because otherwise I’d have editted it like you suggest using #IF(StrPos())
I did think about writing a Utility template, but it kind of defeats the object of having a self contained template in the app which can toggle between the normal and debug runtime, when problems arise.
Yeah, in the Windows System Image Manager which lets you create an GitHub - Intelligent-Silicon/AutoUnattend: Auto Unattend Notes and Examples to install windows without having to touch anything, and install apps including Clarion, baseline seems to be Powershell 5.1, but I have been experimenting with having Powershell removed to reduce the attack vector for devices.
PS C:\WINDOWS\system32> $PSVersionTable
Name Value
---- -----
PSVersion 5.1.26100.4652
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.26100.4652
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
You can install Powershell 2 on Windows XP, which is still useful.
What can a powershell script do that Clarion code can’t?
Powershell can open the Redirection file when its being used by the IDE and change it, the Template language cant.
Couldn’t you write a simple Clarion EXE to #RUN or #RUNDLL and alter the file from the template???
There is the potential that the RED is only read when the solution opens which would mean changing it, by any means, isn’t going to work as you want.
An EXE would work for this situation really well, but ideally I need to find a way to produce a DLL that can be used by any version of Clarion. I noticed handcode projects dont include so much, unlike AppGen DLL’s, so I need to see if I can do a handcode project which would work in every version of the IDE.
So just checked the File Handle for the RED with ProcMon and it looks like its opened as Read, with Read/Write Share, so maybe the #Open requires Read Only which could explain why it wasnt working. Will need to test that.
20:19:33.8159403 Clarion.exe 13240 CreateFile C:\CPUBind\CLARION110.RED SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Random Access, Attributes: n/a, ShareMode: Read, Write, AllocationSize: n/a, OpenResult: Opened
What I was suggesting is that the contents of the RED file have already been read for a given solution/project so changing it afterwards wouldn’t change the currently read contents.
As to Clarion independent, generate the EXE in LIB mode and all the RTL’s are included within the EXE… no external files needed.
My 3rd party installs include LIB based EXE’s that handle unlocks, additions to the default RED file as well as modifications to existing templates - but only for the CRT templates since Larry decided to use something other than REPORT for his templates and the extended targets from SV have to be altered so they’re useful with CRT reports. They were written and compiled in C5 but still work everywhere!!!
When I run the powershell regex swap, and then generate and compile, the IDE uses the debug clarun.dll straight away.
I’ll give that a go cheers.
“When I run the powershell regex swap, and then generate and compile, the IDE uses the debug clarun.dll straight away.”
Sounds like you’re running it before an APP has been opened, maybe not. I wasn’t aware the IDE reloaded while an APP was open.
I have a DLL compiled in Visual C that I use in templates. Requires that you use the ,PASCAL attribute on the #RUNDLL, but other than that, it works fine. I don’t really know ANYTHING about C programming, but it’s not too difficult to cook up a simple DLL to do stuff. Wrote the original code in Borland C 20 years ago I think Might be worth checking into.
Forgot: A C DLL is obviously doesn’t care version of Clarion it is being used with, so there is a big advantage in that.
The template is an #Extension Application
so a global extension template which is where the powershell regex swap is being called from, so yeah the app is open.
I might see if it the C in clarion can do the same. I’ll knock up a simple text app for now to see what mileage I get. I seem to remember doing a clarion handcode project doesnt include alot of the stuff the Appgen includes, so I might get some mileage there. Havent looked into it in any great detail, but need to.
Don’t know anything about the C in Clarion, but it COULD be reliant on some of the version dependent runtime library files, so it may not get you where you want to go in terms of being Clarion version independent.
You might be right, I think it all hinges on how much a clarion language function relies on other functionality found in the runtime, for example a screen control is the screen control ie windows api, plus events handled by the runtime and possibly/probably stuff to make it interface with a variable/driver, hence the need for a Clarion runtime.
I dont know how much StrPos relies on the runtime to work, but there’s only one way to find out…
Remember that you can also use #RUN to run EXEs. If you compile the EXE “local” which includes all the runtime stuff in the EXE then you are no longer relying on the Clarion version. #RUN has been around for a long time and I’ve used it in templates to run Clarion programs independent of Clarion versions.
Yeah, its just I typically use #RunDLL and pass a csv *Cstring to the dll to perform more functions, than the template language allows and Run can’t really do that unless I use a txt file as the conduit, which is an option, but not elegant imo.