DCL edit_box
Is there a way to set the with of an edit_box in Bricscad? The default width of an edit_box in Bricscad appears to be about 1.5X the width in Autocad, so my DCL dialogs do not look the same in both programs. I've tried adding width = lines and fixed_width = true lines but the Bricscad edit_boxes do not change width. The code below is about 3.08" wide on the screen in Autocad but is about 3.98" wide on the screen in Bricscad.
dcl_settings : default_dcl_settings { audit_level = 3; }
faultVCA: dialog {
label = "Fault Calculations" ;
:column
{
:row
{
:boxed_column
{
label = "AFC" ;
: edit_box
{
key = "AFC" ;
action = "(setq AFC$ $value) (test_vals)" ;
}
}
:boxed_column
{
label = "Voltage" ;
: edit_box
{
key = "volts" ;
action = "(setq voltage$ $value) (test_vals)" ;
}
}
:boxed_column
{
label = "Length" ;
: edit_box
{
key = "clen" ;
action = "(setq conduit_length$ $value) (test_vals)" ;
}
}
}
}
ok_cancel ;
}
Comments
-
I found that edit_width helps some, but I haven't been successful in having the borders of the the various boxes align. I think it is time to learn OpenDCL.
0 -
fixed_width_font = true can also help... been in ACAD for as long as I can remember, but new to BCAD.
I gave up on expecting complete compatibility between ACAD dcl and BCAD dcl a long time ago. Most of my dcls are fairly simple and therefore compatible, but the complicated ones are... well, complicated. And sometimes the ACAD version looks like crap in BCAD, and visa-versa.
OpenDCL might be an answer, but then you're depending on someone else, and that, in fact, always leads to extra work. And then you start depending on OpenDCL or DosLib to always be there. What do you do when they're not? Don't get me wrong, both are great products, but I'd rather stick with stuff that's part of the main product - ACAD and BCAD.
So, I set a variable, usingAcad, on start up. Easy to do, and depending on its value, I load either the ACAD dcl or the BCAD dcl.
A little more work, but the frustration level is way down. I'd rather spend an afternoon walking on the beach than fighting the difference in the way ACAD interprets spacer0 and the way BCAD interprets it.
0 -
@ Martin
OpenDCL is the best way to go. That fact that it's open source and has a growing user base eases concerns of it going away anytime soon.
Dan
0 -
With DCL-widths I find that there is usually (always?) a minimum/default setting. Trying to set a width smaller than that is impossible. In the case of the edit_box this setting seems to be 17. If you leave out the width or set it to 17 or smaller it will have the default width. Setting the width to 18 or bigger does have an effect. Using fixed width had no effect in your example because the size of the dialog is dictated by the size of the edit_boxes. So these boxed are already on their fixed width. Using edit_width is a good approach. It works when you want to allign a nummer of edit_boxes. But doesn't work if you want to allign a combination of, for instance, popup_lists and edit_boxes. Note: I am speaking of BC here. I don't have access to AutoCAD.
0 -
A boxed element, column or row, affects the widths of the elements contained in the column or row. Changing the code from boxed_column to boxed_row and inserting a blank text element at the end of the row changes the width of the edit_ box. And edit_limit will control the maximum number of characters accepted by the edit_box.
:boxed_row
{
label = "AFC" ;
: edit_box
{
key = "AFC" ;
action = "(setq AFC$ $value) (test_vals)" ;
edit_width = 2;
}
: text {
label = " ";
}
}0 -
@Larry:
> A boxed element, column or row, affects the widths of the elements contained in the column or row.
I think this is more accurate:
If a row or column, either boxed or not, does not have a width of its own, its width is determined by the elements it contains.
The own width of a row or column can be set by an attribute or determined by its parent element.
In martin's example the size of each boxed_column and consequently the size of the entire dialog is determined by the size of the edit_boxes.
In your example the size of the edit_box is determined by the edit_width only. The dummy text you use only hides the fact that the size of the boxed element around the edit_box is now determined by the size of it's label. Just try your code with the label "Voltage" and you will see what I mean.0 -
Thanks for the replies. I worked with the DCL a bit longer and got most of the layout to an acceptable state, but I'm still having trouble with two lines of instructions at the bottom which are to the left of an edit box -- the white space after the text is almost as wide as the text and I haven't found a way to reduce the white space. I'm also not pleased with the alignment -- the box around an edit box is a few pixels wider than a box for radio buttons, so the left borders do not align. That is not a hugh problem, but it does make the dialog look like it was thrown together.
I am surprised that Bricscad isn't more accurate in drawing DCL dialogs. They want to be 100% compatible with Autocad, but this is one area where they are not even close. I can't see that duplicating the Autocad rendering of DCL boxes would be that hard a task. The difference in DCL renderiing is so obvious that I'd think fixing it would be a priority since most users are going to judge BC as much on how it looks as on how well it works.
I tend to agree with Daniel that OpenDCL is the way to go. I don't think Owen will drop OpenDCL any time soon (I use some of his connercial products, too), and since ODCL is open source I could always recompile myself if I had to. Drawing the dialog box in ODCL was easy. I'm on the learning curve for interfacing ODCL with lisp.
0 -
Ah: The "Ugly Right Margin Issue". According to BC support this is AC-compatible.
Workaround:faultVCA : dialog {
label = "Fault Calculations";
: textRow {: text {value = "This is a line of text that is rather long";}}
: textRow {: text {value = "And this text is much, much, much, much, much, longer";}}
ok_cancel ;
}
textRow : row {children_alignment = centered; fixed_width = true;}0 -
>I am surprised that Bricscad isn't more accurate in drawing DCL dialogs.
I can understand your surprise.
The main reason for the DCL layouting differences is that the Bricscad dcl engine uses wxWidgets, not MFC. Simulating a Layouting engine in another layouting engine, using other fonts, other controls... is not a trivial task, perhaps even impossible to do it perfectly.
The reason for writing our dcl engine in wxWidgets is portability. DCL will be supported in our linux version and future mac version. But frankly, I doubt a typical mac user will like the look of DCL dialogs.
Mind that DCL is an old technology. When it was first invented, gui interfaces were not what they are today.
0 -
Tijs,
Thank you for the clarification.
Martin
0
