Recent Posts

Pages: [1] 2 3 ... 10
1
Project Administration / Re: OpenDCL for Mac
« Last post by owenwengerd on October 13, 2019, 09:35:53 PM »
Autodesk would need to provide some sort of Mac equivalent to the (MFC based) CAdUi classes before a Mac version would become feasible. I don't see that ever happening on Acad.
2
Deployment / Re: BricsCAD V20
« Last post by BIG-AL on October 07, 2019, 04:22:37 PM »
Hi Owen

Sorry to hijack this post but was looking for wether a version is being looked at for the MAC its still there and getting pushed by Autodesk despite being a sort of lisp + LT.

Did post under Mac question.

Thanks
3
Project Administration / Re: OpenDCL for Mac
« Last post by BIG-AL on October 05, 2019, 07:27:24 PM »
Hi Guys

I have posted here on this old post about the Mac Autocad version now 2020 and no dcl support ?

Has opendcl progressed any further ?

Regards
4
Deployment / Re: BricsCAD V20
« Last post by Coert on October 04, 2019, 12:18:02 AM »
Hi Owen,

When can we expect the update for BricsCAD V20?
5
Studio/Dialog Editor / Check Marks on Tree Nodes
« Last post by Jim Short on September 21, 2019, 09:49:22 AM »
Has anyone figured out how to toggle a check mark on a tree. I don't think there is a way to do more than fire the select event for the whole node.
6
Runtime/AutoLISP / Picture method versus LoadPictureFile with HiDPI
« Last post by honkinberry on September 06, 2019, 08:32:11 AM »
For compatibility with HiDPI monitors, we are able to use the LoadPictureFile method with the Stretch parameter.  So for a 32x32 PictureBox, we make a 64x64 image, and it will work for both HiDPI and standard DPI displays.
But when using the Picture method to specify an image from the project picture folder, there is no Stretch parameter.
So one solution would be to store both standard and HiDPI images in the project picture folder, and then at runtime set the appropriate one.
What I would definitely prefer, is if the Picture method either had a Stretch parameter, or automatically applied a stretch.  The same for Graphic Buttons -- either I need to check the registry for HiDPI, and set both Picture and Mouse-Over Picture accordingly, or it could just automatically stretch the image assigned at design-time.
Thanks for reading!

--J
7
Runtime/AutoLISP / Re: BricsCAD v20 Beta
« Last post by Mike Dennis on September 04, 2019, 07:29:39 PM »
Thank you, sir!!
8
Runtime/AutoLISP / Re: BricsCAD v20 Beta
« Last post by owenwengerd on September 04, 2019, 06:38:22 PM »
An update is coming "shortly".
9
Runtime/AutoLISP / BricsCAD v20 Beta
« Last post by Mike Dennis on September 03, 2019, 01:24:15 PM »
Hi,

Just a "heads up" that BricsCAD v20 beta is out (at least to developers).

No pressure to our fantastic OpenDCL developers, but the current OpenDCL runtime does not seem to work with this beta release.

Mike Dennis
10
Runtime/AutoLISP / Re: More DragDrop woes
« Last post by honkinberry on August 30, 2019, 04:34:12 PM »
Well, after a frustrating day, I have an interim fix.
Still would love the sky gods to hear my plea.
But here is some code that addresses a few of the issues with DragDrop on a ListBox:

Code: [Select]
(defun c:dclDragDrop (proj form control drop / n i C Y HIDPI new)
    (if (and (setq n (dcl-ListBox-GetCurSel List1)) ; after drag, current item should still be selected
            (> n -1) ; something selected (although by definition it should be at end of a drop)
            SOURCELIST ; should also already exist in order to populate the listbox
            (> (length SOURCELIST) 1) ; just save us from having to find out otherwise they accidentally dragged a 1-item list
            (setq C (nth n SOURCELIST)) ; current item dragged
             ; now let's see where they dragged it
            Y (cadr drop) ; it's a listbox, the X value is pointless to us
             ; but on HiDPI these values will be doubled! we need to find that out
            HIDPI
                (and (setq i (vl-registry-read "HKEY_CURRENT_USER\\Control Panel\\Desktop\\WindowMetrics" "AppliedDPI"))
                    (> i 150)
                ) ; and
             ; so my actual Y drop point was:
            Y (LM:round (/ Y (if HIDPI 2.0 1.0)))
             ; let's translate pixel to nth list position
            new (LM:round (/ Y 12.5)) ; listbox items at default font/size/scaling are consistently 12.5 pixels apart
             ; but user can drag far past the last item in the list, we need this to at most be 1+ the last nth position
            new (min new (length SOURCELIST))
             ; ah, 1 last thing to validate.  if they dropped it either just before or after existing position.
             ; before will be the same as n, after will be 1+.  so to drag after the *next* item, it would need to be +2
            (not (member new (list n (1+ n)))) ; otherwise, we have a valid drop!
        ) ; and

        (progn
             ; effect the drop!
             ; list item C, user would prefer it at nth position "new"
        ) ; progn

    ) ; if
) ; DragDrop

I hope that is pretty clear, that is just an unacceptable amount of code to wrangle for every ListBox DragDrop.
Especially compared to the simplicity of a Tree Control drag/drop.
Note also, that it is not accounting for a font, size, or font scaling, other than default, so this still isn't done.

--J
Pages: [1] 2 3 ... 10