@baitang36This is a tool, one click merge. One file is simpler and better managed than two files
This very much reminds me on this :
http://www.theswamp.org/index.php?topic=52907.msg608920#msg608920
(I don't know if you looked at it already...)
In what scenario do we need to merge DCL and LSP that are performing things accordingly to predominantly LSP codings (callings) when DCL is supposed to be called?
The problem is that with my link, master LSP also needs to point to location (path) of file itself (LSP/DCL), wasting time therefore... I can see that you also forces (getfiled) to browse for file(s)...
Are you after that establishing treatment of DCL in native form flexible for manipulations and in the same time applying it's real runtime performance through master LSP?
In what case do we really need merging, if DCL can't be hooked to normal compact textual expression reserved for Dialog Control Language in it's true basic written language formulation (how it's supposed to be used/written when writing it from scratch/starting point)?
I can't recall now for what I did in past, but it was very similar to this... Here is the topic - on the swamp - search for @Inreb and me, and "DCL to LSP" or similar...Indeed, many people have done DCL to LSP before. My innovation is to automatically process load_ Dialog statement. It is very simple for the program to automatically find and replace.
And regarding that of your code and based on my previous experiences : consider using (vl-prin1-to-string) function to parse it to (write-line) to DCL->LSP on the fly... Much simpler, and much more effective and also very proficient in terms of errors - with "" characters or... RegEx... or...wildchar */?@#$% ...???