Need help testing and improving my lisp

[roland.r71]

Hi guys,

Attached you will find my MFT.lsp, which stands for "Multiple Filehandling Tool"

It allows to select files (*.dwg / *.dxf), in pretty much any way thinkable.

& to suply a lisp (*.lsp) to be loaded and/or commands to be executed, on each file.

MFT Main dialog

The idea is to share this with anybody who needs to process multiple DWG's (or DXF's).

& Its supposed to work on any version of ACAD, in combination with DOSlib.

...but I can only test it on 2014 (64bit) & 2015 (64bit)

...and the code can surely be improved in many ways. (which comes with a ton of comments)

& thats what I need you guys for.

Any version you can test it on, any bug you find, any improvement you can make, any suggestion you have: Bring it on! (& make this a tool everybody wants )

Note: the command part is an addition I stuck in recently and still need to work out a bit.

The idea was to create a script & load that with each drawing, but that doesn't work.

So I changed it to an (eval ...), which works with the example you see inside the screenshot above, but I didn't yet test it with multiple lines and/or script like commands (e.g: "Zoom e" instead of "(command "zoom" "e")")

I might just reduce the option to a single line of code, if it turns out to difficult to allow for more. (& if you put 'garbage' in, you will get garbage out during processing, so be carefull with that option)

It comes with a ini file & dcl for the main dialog.

I've used "C:/Lisp/MFT/" to put the files in & it uses a subdirectory "DATA" for saving a list of files and a .scr file to hold the commands. It doesn't check or create it, so if not there, nothing will be saved/loaded for those two files/options.

You should be able to put it anywhere, just edit the path inside the .lsp INIT section

   (setq MFT_files "c:/Lisp/MFT/")

Where you might also set a path to find DOSlib. (It will try to find it within support path first)

   (setq DLpath "C:/Lisp/DOSLIB/")

[roland.r71]

Have a nice vacation then.

I'll see if I can get that list_box up and running for the main dialog in the mean-time.

Having the list visible (& editable) right there has always been my wish, but 11-14 years ago I couldn't get it done. (I created the first version back in 2004. version 2.1 comes from 2007 (& a minor update for acad2011 back in 2010 to version 2.2))

Now I (think I) can.

Just reworked my checking procedure too. That part of code was 14 years old & always worked perfectly, but it could definately use an update, code & speed wise. Now it should be a lot faster as I don't just always check the entire list anymore, unless I have to. Still need to add some new code for the dialog options, so it will for example only check for duplicates when turned on, instead of just performing a complete check. This should increase its performance with huge lists (1000 or more) significantly.

[john.uhden]

I like your philosophy. Later...

[scot-65]

I had an opportunity of reviewing the latest DCL you attached.

Some items I see that might need clarification...

First off, when DCL was first developed, everything is called a "tile".

These days, the terminologies are "Container" and "Control".

I will use these modern terminologies here.

:dialog, :row, :column, :radio_row, etc. are containers.

The rendering order for a :dialog is a column from top to bottom.

No need to wrap a first level container :column for just one control. Same for :row.

The use of :column that is not first wrapped by a :row is redundant.

No need to wrap a first level container :column for multiple controls inside the column.

Attribute alignment=L/C/R; of controls itself that are grouped together inside a :row is redundant.

If a control is all by itself as a row, fixed_width=true; and alignment=C/R;. Left is redundant.

If a :row is fixed_width=true; then the controls inside do not require this same attribute.

Positioning a container attributes fixed_height=true; and alignment=T/B;. Center is redundant.

Use fixed_width=true for the :row and use either width=##; to a control or spacers with assigned

width to position the (next) control.

Advanced users #1:

Constants can be used to reduce the character count of the DCL dialog definition.

Here is an example.

// original code

:row {fixed_width=true; alignment=centered;

 :button {key="But1"; label="First"; width=12.0;}

 :spacer {width=2.0;}

 :button {key="But2"; label="Second"; width=12.0;}

 :spacer {width=2.0;}

 :button {key="But3"; label="Third"; width=12.0;}

}//row

For the above example, there will more than one row that requires fixed width / alignment

and the buttons are all the same width (notice that the row is fixed_width therefore the

buttons do not require the fixed width attribute).

Now to simplify:

// constants

rfwtac :row {fixed_width=true; alignment=centered;}

but12 :button {width=12.0;}

spw2 :spacer {width=2.0;}

// resulting code

:rfwtac {

 :but12 {key="But1"; label="First";}

 spw2;

 :but12 {key="But2"; label="Second";}

 spw2;

 :but12 {key="But3"; label="Third";}

}//row

Advanced users #2:

When one creates multiple dialogs and builds a library of "modules",

each module begins it's life as a container with the controls inside.

// modules:

header :row { [control definitions here] }

body1 :column { [control definitions here] }

body2 :column { [control definitions here] }

footer :row { [controls such as OK, Cancel and Help buttons] }

// and now the dialogs:

MainDialog :dialog {header; body1; footer;}

SecondDialog :dialog {header; body2; footer;}

Advanced users #3:

Incorporate the DCL definition into the LISP so as only one file (that can be a FAS).

See attachment.

I was able to reduce total character count of this dialog by 30%.

Bonus is the behavior of the first three toggles.

Scot-65

[roland.r71]

Thnx!

That's a lot of (welcome) info.

I just made a few rigorous changes to the dialog. Cutting it (back) into two parts for one.

The upper "settings" part & the lower "fileselection" part are separate (again). This to allow for wrapping the fileselection into any lisp function. Same for the "processing" part.

The biggest change: The file selection part now has the filelist visible and editable.

It used to be "hidden" behind the "edit" button.

So, I'll have to see what exactly you did there and 'copy' that to the new version.

edit:

Preview of the new dialog (for file selection) - note: this is from a separate test, so not all is set.

[roland.r71]

I finnished up my work on the dialogs (using @scot-65's work) & splitting up the functions. With previous versions the file selection & processing (script generator, back then) could be called separately. I initially chose not to do so for this version. But it is way more versatile if they are.

So:

MFT will get you the full thing, starting with a dialog for setting options & commands (lisp and/or script)

If you click "Select files", you get the file selection dialog.

-or- you can use something like: (setq list (MFT_getFiles))

When clicking "Process" (main dialog)

it will process the selected files & load a lisp and/or execute the script

-or- you can use:(MFT_Process [list with files] [list with commands/arguments])

e.g:(MFT_Process (MFT_getFiles) (list "zoom" "e"))

This version will generate the dcl file too. Next to the ini file & import filter for log files & directories needed.

So there's no need for any other file but the main MFT.lsp file. Just put it where you wish & make sure to set the correct path inside the function. (top function MFT_Config holds all settings)

look for:

   ; *******************************************
   ; *** start of user configurable settings ***
   ; *******************************************

      ; Set path to this file - NOTE: use either \\ or / instead of \
      (setq MFT_files "e:/Lisp/MFT/")

      ; Optional path to be used to find/load doslib
      (setq DLpath "e:/Lisp/DOSLIB/")

& change to fit yours.

Note: It is recommended to remove all files & (sub)directories if you have tested a previous version.