Deviations from AutoCAD functionality for those porting existing software

Dear Steve,
just some answers ...

for #13 XData :
under which conditions do you get ((1001 . "LYR_STD") (1000 . "BASIC")) in AutoCAD,
where BricsCAD does not return the same sequence ?
As this should be fixed, indeed.
Using (entget ename (lisp "*")) or (entget ename (lisp "MyApp")) returns the same
list using -3 sentinel as AutoCAD does

for #1 / #2 :
yes, this is a known difference ... I will try to get this fixed for Lisp + BRX;
internally that extra newline is necessary for some connabds, but for Lisp + BRX we
should find a way to suppress extra newline

for #3 Lisp -> ARX -> acedCommand :
will try to reproduce, this needs to be fixed

for #4 (entmake) for existing anonymous blocks
shouldn't (entmod) be used better ? (entmake) always creates a new object ...
maybe, you can erase the existing block definition just before creating a new one ?

for #5 '+' syntax in menus
already fixed, will be in upcoming V13.2.

for #11 '49' missing DXF code for linetypes
I will fix this right afterwards

for #12 (ssget) order
yes, also a known issue ... I already have a fix for this, which will provide
same order as AutoCAD does, for "X", "C", "CP", "W", "WP" modes ... will likely
be included in one of next BricsCAD;
BUT
it is simply not correct to rely on particular order of entities within a selectionset;
of course, AutoCAD has that behaviour, but it is not guaranteed at all.
Furthermore, ARX/BRX provide reactor interfaces for entity selection - therefore, applications
can add/remove entities to/from selectionsets, causing unpredictable entity order.

So in summary, it is bad application logic to rely on the entity order - strongly
advised to rework the application logic here.

As mentioned, it will get better in BricsCAD, but likely will never be 100% as in AutoCAD.

--------

For these and the others, please feel free to send us a "support request" (bug report),
1 item per request please, so we can better schedule the issues to our developers.

Especially the issue #3, #6, #8, #11, #13 seem worth to be documented.
If possible, please provide a sample dwg and/or some Lisp snippets to reproduce,
this makes it easier for us to reproduce.

The Forum has eaten some of the entiylist in my previous post. It should be:
[code](
  (-1 . <Entity name: 0ce4a6f0>)
  (0 . "LTYPE")
  (5 . "9E")
  (330 . <Entity name: 0ce68660>)
  (100 . "AcDbSymbolTableRecord")
  (100 . "AcDbLinetypeTableRecord")
  (2 . "CENTER")
  (70 . 0)
  (3 . "Center ____ _ ____ _ ____ _ ____ _ ____ _ ____")
  (72 . 65)
  (73 . 4)
  (40 . 50.8)
  (49 . 31.75)
  (74 . 0)
  (49 . -6.35)
  (74 . 0)
  (49 . 6.35)
  (74 . 0)
  (49 . -6.35)
  (74 . 0)
)[/code]

Dear Steve, Dear Roy,

for #11 : linetype dxf 49
indeed, (entget (tblobjname "LTYPE" ...)) works correctly;
it is (tblsearch) and (tblnext) which incorrectly omitted dxf 49 ... as the data list shows, Acad creates the datalist not by internal (entget),
but in dedicated code; we also do so since V13, for performance reasons.

The issue with dxf 49 has been fixed internally, and such case was added to the test system.

for #13 XData list
I'm highly interested to get this solved, if there is any difference to AutoCAD - please provide a small sample and/or code snippet

Many greetings !

issue #13. XData difference
just fixed in our code ... now behaves as expected; many thanks !

@Bruce:
You are right, but the problem only seems to occur when the radio_column or radio_row is the first 'clickable' tile in the dialog. When you say 'returns a nil value' I assume you mean the callback function for the radio_button is not triggered even though is appears as selected.

After some experiments I have found a workaround for this. Don't know how this will work in AutoCAD.

LSP:
[code](defun c:DCL_Test ( / N_Accept N_Option1 N_Option2 N_Option3 dclFile)
  (defun N_Accept ()
    (print (get_tile "options"))
    (print (get_tile "option1"))
    (print (get_tile "option2"))
    (print (get_tile "option3"))
  )
  (defun N_Option1 ()
    (print "Option 1 was selected")
  )
  (defun N_Option2 ()
    (print "Option 2 was selected")
  )
  (defun N_Option3 ()
    (print "Option 3 was selected")
  )
  (setq dclFile (load_dialog "DCL_Test"))
  (new_dialog "DCL_Test" dclFile)
  (action_tile "option1" "(N_Option1)")
  (action_tile "option2" "(N_Option2)")
  (action_tile "option3" "(N_Option3)")
  (action_tile "accept" "(N_Accept)")
  (start_dialog)
  (unload_dialog dclFile)
  (princ)
)[/code]

DCL:
[code]DCL_Test : dialog {
  label = "DCL_Test";
  : radio_column {
    key = "options";
    value = "";                                                        // Set value as workaround for radio problem.
    : radio_button {key = "option1"; label = "Option 1"; value = "1";} // Set value as workaround for radio problem.
    : radio_button {key = "option2"; label = "Option 2";}
    : radio_button {key = "option3"; label = "Option 3";}
  }
  ok_only;
}[/code]

Torsten,

I am ok with how things are now, I was just bringing to the attention of any interested programers.  However as Roy pointed out, even within Bricscad the only instance where the 1st radio button appears selected is if the radio column/row is the first set of inputs within the DCL.

Bruce