Discrepancies in DCL Quality: Addressing Graphical Issues Between Systems

[Anonymous]

Why does this difference in DCL quality occur? It looks perfect on my computer, but when I deliver it to my client, there's this discrepancy, and the graph looks strange. Does anyone know how to fix this issue?

in my computer:

on the client's computer

[komondormrex]

since it is supposedly not built-in dcl you in first place have to check that your client have same arx library as you to load open dcl.

[Anonymous]

@komondormrex This is an integrated DCL hahaha lol

I'm thinking it's because my client's desktop doesn't have the same graphics card as mine, but I don't think there's anything to that.

[JamesMaeding]

I'm thinking this is because of "high DPI" handling on their end.

I have some of the same issues but with .net dialogs.

If you are using OpenDcl, which I use extensively, mention what version you are on.

Maybe post your .odcl file and I will try displaying it on my system.

Really, if ODCL, you should use their forums. thx

[Anonymous]

@JamesMaeding  I'm not using anything, this is a normal DCL, just a splitter and the image vector.

[JamesMaeding]

@Anonymous 

Thanks for clarifying.

You are likely not going to solve the issue as autodesk will not modify anything related to lisp.

I would say this might be a blessing, as OpenDCL is amazing and free.

It has a graphical UI for making the dialog, and saves so much time with how it implements callbacks and events like VB, .net, and most languages with forms.

You can debug easier too.

I got into that for 15 years and then into .net when it became a thing.

All my major dialogs are done in .net, and I can call from lisp so no ODCL needed on them, and I get the good windows handling for high DPI monitors.

That is a major rabbit hole but the ODCL jump is not too bad. You need an example to get started, and then some instruction on how to compile all to one vlx that is "separate namespace" so variables are not exposed like in uncompiled files like .lsp.

I bet your programming skills are good though based on your program so might be the right solution to go ODCL.

[komondormrex]

well, seems that i supposed wrong)))

[Anonymous]

@JamesMaeding  thank you very much, but I can create forms with CSharp. What I wanted was to find out why this difference between computers is happening.

@komondormrex Yes, it's just a simple DCL

[komondormrex]

i was just misled with this

have you done the map and entities selected with (start_image), (vector_image), (end_image)?

[Anonymous]

I did this with vector_image and Slider.
I wanted to find out the reason for this difference between computers. the other DCLS also present differences.

[JamesMaeding]

@Anonymous 

How would you ever really know what's causing it?

You would have to guess, and see if changing that thing to the setting or hardware on the "good" machine fixed it.

Of course, if adesk tells you, its likely the right answer but we are not them.

Even if you get the right answer it leaves you with no fix.

You've pushed dcl pretty far, nice job!

[CodeDing]

@Anonymous 

Honestly, it looks like everything about their dialog is displaying larger (check boxes, text, etc.). It looks like perhaps their Windows display settings are adjusted.

Maybe something like this setting:

Or if they have multiple displays, maybe this setting:

Best,

[komondormrex]

it is strange enough, since the zero point for image drawing is left upper corner of image tile and your map is drawn obviously not from there. 

[JamesMaeding]

@Anonymous 

That's what I said earlier, the "high DPI" settings.

I've been struggling with that for several years now in .net, and finally got to correct settings  to handle stuff. Even autocad has a few dialogs not set correctly and they freak out on high dpi scaling.

The civil3d batch converter is one.