Locating dialog_modal windows

[klewlis]

Please see the attached code

When opening a dialog_modal window the UpperLeftX and UpperLeftY do not work the same as they do with any other window.  When running my program in the LB editor, the window is drawn in a different location than that specified.  If I run the program in "debug" mode, the windows appear to be drawn in the correct location.  My current work around is to use "SetWindowPos", but this has a little flash as the window is drawn on the screen then moved by my API call.  

example
UpperLeftX = int((DisplayWidth - WindowWidth) / 2)

UpperLeftY = int((DisplayHeight - WindowHeight) / 2)


this sets the upper left corner of the window in the center of the screen, instead of centering the window on the screen.  Warning, I have not cleaned up this code yet, so there are commented lines and the window size is larger than needed.


'----- This is now the "about" window

sub instruct

'----- Pre-window set up

   nomainwin

   WindowWidth = 550

   WindowHeight = 445

   'UpperLeftX = int((DisplayWidth - WindowWidth) / 2)

   'UpperLeftY = int((DisplayHeight - WindowHeight) / 2)

   'UpperLeftX = 10

   'UpperLeftY = 10

   UpperLeftX = int((DisplayWidth - WindowWidth) / 4)

   UpperLeftY = int((DisplayHeight - WindowHeight) / 4)



'----- Information to be displayed

   button #Instruct.button1,"GOT IT ",[quit.instruct], UL, 455, 380, 70, 25

   statictext #Instruct.statictext1, "ALL ROOF PITCHES MUST MATCH!   ALL WALL HEIGHTS MUST MATCH!", 5, 5, 525, 20

   statictext #Instruct.statictext2, "If there is enough interest, these features may be added at a later time", 5, 35, 450, 20

   statictext #Instruct.statictext3, "This program will calculate rafter, ridge, hip and valley lengths.", 5, 75, 490, 20

   statictext #Instruct.statictext4, "It will also calculate the following jack rafter lengths:", 5, 105, 325, 20

   statictext #Instruct.statictext5, "Ridge to Valley, Hip to Wall, Hip to Valley and Ridge to Ridge.", 5, 135, 400, 20

'    statictext #Instruct.statictext6, "When inputting measurements, the following conventions must be followed:", 5, 175, 450, 20

'    statictext #Instruct.statictext7, "Feet and inches must be separated with a dash, (e.g. 19-6).", 5, 205, 570, 20

'    statictext #Instruct.statictext8, "Foot, ('), and inch, (" + chr$(34) + "), marks are allowed, (e.g. 19'-6" + chr$(34) + "), but are not required.", 5, 235, 500, 20

'    statictext #Instruct.statictext9, "Use of the foot mark, (') does not require use of the inch mark, (e.g. 19'-6).", 5, 265, 520, 20

'    statictext #Instruct.statictext10, "Fractional inches must be separated from whole inches with a space, (e.g. 19-6 3/8).", 5, 295, 530, 20

'    statictext #Instruct.statictext11, "Decimal inches require a decimal point, (e.g. 19-6.375).", 5, 325, 450, 20

'    statictext #Instruct.statictext12, "Ridge Width must be expressed as inches only, (e.g. 1 1/2 or 1.5).", 5, 355, 450, 20

'    statictext #Instruct.statictext13, "Roof pitch must be expressed as a fraction, Rise / Run, (e.g. 6/12).", 5, 385, 450, 20



'----- Open "about" window

   open "About Rafter Master" for dialog_modal as #Instruct

   print #Instruct, "font times_new_roman 12"

   print #Instruct, "trapclose [quit.instruct]"



'----- Wait here for button click

[Instruct.inputLoop]

   wait



'----- Close "about" window

[quit.instruct]

   close #Instruct

end sub


The fact that it appears to work in "debug" mode, but not in "run" mode is perplexing.  you can try all three options for ULX and ULY and see what happens

[tsh73]

as I remember dialog window positions along "master" (parent) window, not whole desktop.
So if you open ordinary window then dialog, it will be shown relative to ordinary window.
Open it small in a right spot and call dialog with minimal offset? (try below code)

My guess in debug mode it shows relative to debugger window (or a mainwin).
interesting but is obviously not
Just my 0.02$

---

'----- This is now the "about" window
call instruct

sub instruct

'----- Pre-window set up

   nomainwin

   WindowWidth = 550

   WindowHeight = 445

   'UpperLeftX = int((DisplayWidth - WindowWidth) / 2)

   'UpperLeftY = int((DisplayHeight - WindowHeight) / 2)

   'UpperLeftX = 10

   'UpperLeftY = 10

   'it's /2 if you want center
   UpperLeftX = int((DisplayWidth - WindowWidth) / 2)
   UpperLeftY = int((DisplayHeight - WindowHeight) / 2) 'not really center, I dunno

   'small window
   WindowWidth = 1
   WindowHeight = 1
   open "tmp" for window_popup as #tmp

   'real window
   WindowWidth = 550
   WindowHeight = 445
   UpperLeftX = 1

   UpperLeftY = 1



'----- Information to be displayed

   button #Instruct.button1,"GOT IT ",[quit.instruct], UL, 455, 380, 70, 25

   statictext #Instruct.statictext1, "ALL ROOF PITCHES MUST MATCH!   ALL WALL HEIGHTS MUST MATCH!", 5, 5, 525, 20

   statictext #Instruct.statictext2, "If there is enough interest, these features may be added at a later time", 5, 35, 450, 20

   statictext #Instruct.statictext3, "This program will calculate rafter, ridge, hip and valley lengths.", 5, 75, 490, 20

   statictext #Instruct.statictext4, "It will also calculate the following jack rafter lengths:", 5, 105, 325, 20

   statictext #Instruct.statictext5, "Ridge to Valley, Hip to Wall, Hip to Valley and Ridge to Ridge.", 5, 135, 400, 20

'    statictext #Instruct.statictext6, "When inputting measurements, the following conventions must be followed:", 5, 175, 450, 20

'    statictext #Instruct.statictext7, "Feet and inches must be separated with a dash, (e.g. 19-6).", 5, 205, 570, 20

'    statictext #Instruct.statictext8, "Foot, ('), and inch, (" + chr$(34) + "), marks are allowed, (e.g. 19'-6" + chr$(34) + "), but are not required.", 5, 235, 500, 20

'    statictext #Instruct.statictext9, "Use of the foot mark, (') does not require use of the inch mark, (e.g. 19'-6).", 5, 265, 520, 20

'    statictext #Instruct.statictext10, "Fractional inches must be separated from whole inches with a space, (e.g. 19-6 3/8).", 5, 295, 530, 20

'    statictext #Instruct.statictext11, "Decimal inches require a decimal point, (e.g. 19-6.375).", 5, 325, 450, 20

'    statictext #Instruct.statictext12, "Ridge Width must be expressed as inches only, (e.g. 1 1/2 or 1.5).", 5, 355, 450, 20

'    statictext #Instruct.statictext13, "Roof pitch must be expressed as a fraction, Rise / Run, (e.g. 6/12).", 5, 385, 450, 20



'----- Open "about" window

   open "About Rafter Master" for dialog_modal as #Instruct

   print #Instruct, "font times_new_roman 12"

   print #Instruct, "trapclose [quit.instruct]"



'----- Wait here for button click

[Instruct.inputLoop]

   wait



'----- Close "about" window

[quit.instruct]

   close #Instruct
   close #tmp  'close temp window

end sub



[klewlis]

You are absolutely right, so this is what I did.

At the set up for my main window I added global variables for the window width and window height of the main window.

'----- Pre-window set up
   nomainwin
   WindowWidth = 1400
   WindowHeight = 722
   UpperLeftX = int((DisplayWidth-WindowWidth)/2)
   UpperLeftY = int((DisplayHeight-WindowHeight)/2)

   MWW = 1400
   MWH = 722
   global MWW
   global MWH


Then at the dialog I modified my ULX and ULY as follows.

   
   UpperLeftX = int((MWW - WindowWidth) / 2)
   UpperLeftY = int((MWH - WindowHeight) / 2)


This centered the dialog on the main window, unless I ran it in "debug" mode. It appears that in debug mode the editor inherits the dialog window and it is placed accordingly.

I do believe this is a bug, as it behaves differently depending on the mode the editor is run in.

[Dennis]

Reading this thread got me thinking as to why I had not used dialog_modal on some of my windows. When converting from a previous BASIC (where I had used dialog_modal) to LB, I went with an elaborate set of switches and logic to ensure that a open window was closed before selecting the next function.

I vaguely remembered having tried dialog_modal but for some reason had abandoned it. I decided to try again.

I took a perfectly functioning window (see code below) and changed the open statement from window to dialog_modal. The attachment shows the before and after. Opening with window works perfectly, but the dialog_modal attempt shrunk the controls and distorted the captions.

At first I thought that the STYLEBITS statement was interfering so I rem'd it out and tried again. No change - still shrunken and distorted. With the STYLEBITS active, clicking anywhere in the title bar closed the window. With the STYLEBITS inactive that problem disappeared.

I am obviously doing something wrong. My system has something like 45 windows that can use the dialog_modal approach but the last thing that I want to do is to change all the sizing and fonts!! All I want to do is to change the open statement and perhaps play with the STYLEBITS.

In the previous BASIC that I used, a change from windows to dialog kept everything the same.

Any comments about what I am doing wrong?

Thanks

Dennis

Screens.pdf (397.14 KB)

WindowWidth = 450
WindowHeight = 380
UpperLeftX = 570
UpperLeftY = 20

YOffset = 8

statictext #IssueID.statictext6, "Short Description:", 13, YOffset, 125, 20
textbox #IssueID.ShortDescrip, 146, YOffset, 210, 25
statictext #IssueID.statictext7, "Long Description:", 15, YOffset+45, 125, 20
Stylebits #IssueID.LongDescrip, _WS_VSCROLL OR _ES_MULTILINE, _ES_AUTOHSCROLL, 0, 0
textbox #IssueID.LongDescrip, 146, YOffset+45, 265, 80
statictext #IssueID.Status, "", 15, YOffset+70, 125, 20
statictext #IssueID.Status2, "", 15, YOffset+90, 125, 20
statictext #IssueID.statictext7a, "Date identified:", 33, YOffset+143, 110, 20
textbox #IssueID.Date, 146, YOffset+140, 80, 25
statictext #IssueID.statictext8, "Issue type:", 64, YOffset+188, 80, 20
combobox #IssueID.Type, TypeLU$(), [GetIssueType], 146, YOffset+185, 130, 25
statictext #IssueID.statictext10, "What triggered:", 32, YOffset+228, 110, 20
combobox #IssueID.Trigger, TriggerLU$(), [GetIssueTrigger], 146, YOffset+220, 150, 25
statictext #IssueID.statictext10, "Classification:", 32, YOffset+258, 110, 20
combobox #IssueID.Class, ClassLU$(), [GetIssueClass], 146, YOffset+255, 150, 25
button #IssueID.OK,"OK",[OKIssueID], UL, 180, YOffset+300, 50, 25
button #IssueID.Cancel,"Go Back",[quit.IssueID], UL, 250, YOffset+300, 75, 25

STYLEBITS #IssueID, 0, WS.SYSMENU OR WS.CAPTION, 0, 0

open "Issue Details" for window as #IssueID

print #IssueID, "font ms_sans_serif 10 bold"
print #IssueID, "trapclose [quit.IssueID]"

[tsh73]

Just run your code on Win 10
(just stylebits remmed out because of JB)
window or dialog od dialog_modal -- at start all the same, looks OK

BUT
just yesterday I seem similar problem on another computer
it had dialog window BIGGER then normal one.
Happened to be because of interface scaling set to 125%
(and not "normal" scaling to 125, which increase both dialog and normal window, but Advanced scaling, whch somehow leaved normal window but scaled only dialogs)

EDIT
I remember dialog not scaling on "refresh" command, I put it on your OK button and it produces same garbled output.
Are you doing something along
#IssueID "refresh"
?


nomainwin

WindowWidth = 450
WindowHeight = 380
UpperLeftX = 570
UpperLeftY = 20

YOffset = 8

statictext #IssueID.statictext6, "Short Description:", 13, YOffset, 125, 20
textbox #IssueID.ShortDescrip, 146, YOffset, 210, 25
statictext #IssueID.statictext7, "Long Description:", 15, YOffset+45, 125, 20
'Stylebits #IssueID.LongDescrip, _WS_VSCROLL OR _ES_MULTILINE, _ES_AUTOHSCROLL, 0, 0
textbox #IssueID.LongDescrip, 146, YOffset+45, 265, 80
statictext #IssueID.Status, "", 15, YOffset+70, 125, 20
statictext #IssueID.Status2, "", 15, YOffset+90, 125, 20
statictext #IssueID.statictext7a, "Date identified:", 33, YOffset+143, 110, 20
textbox #IssueID.Date, 146, YOffset+140, 80, 25
statictext #IssueID.statictext8, "Issue type:", 64, YOffset+188, 80, 20
combobox #IssueID.Type, TypeLU$(), [GetIssueType], 146, YOffset+185, 130, 25
statictext #IssueID.statictext10, "What triggered:", 32, YOffset+228, 110, 20
combobox #IssueID.Trigger, TriggerLU$(), [GetIssueTrigger], 146, YOffset+220, 150, 25
statictext #IssueID.statictext10, "Classification:", 32, YOffset+258, 110, 20
combobox #IssueID.Class, ClassLU$(), [GetIssueClass], 146, YOffset+255, 150, 25
button #IssueID.OK,"OK",[OKIssueID], UL, 180, YOffset+300, 50, 25
button #IssueID.Cancel,"Go Back",[quit.IssueID], UL, 250, YOffset+300, 75, 25

'STYLEBITS #IssueID, 0, WS.SYSMENU OR WS.CAPTION, 0, 0

' !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
   'open "Issue Details" for window as #IssueID
   'open "Issue Details" for dialog as #IssueID
   open "Issue Details" for dialog_modal as #IssueID
' !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

print #IssueID, "font ms_sans_serif 10 bold"
print #IssueID, "trapclose [quit.IssueID]"

wait

[quit.IssueID]
close #IssueID
end

[OKIssueID]
#IssueID "refresh"
wait



[Rod]

The help file is very specific about LOCATE REFRESH, these commands are only for windows of type WINDOW.

[Walt Decker]

Dialog windows are different from API windows. Dialogs are created using DIALOG UNITS which are about 8 pixels per unit. To get the true ratio for dialog units:

User32.DLL function:

"GetDialogBaseUnits", UnitSize AS LONG

Return Values

The return value is a 32-bit value that contains the dialog base units. The low-order word of the return value contains the horizontal dialog box base unit, and the high-order word contains the vertical dialog box base unit.

Remarks

The horizontal base unit is equal to the average width, in pixels, of the characters in the system font; the vertical base unit is equal to the height, in pixels, of the font. Furthermore, each horizontal base unit is equal to 4 horizontal dialog units; each vertical base unit is equal to 8 vertical dialog units. Therefore, to convert dialog units to pixels, an application applies the following formulas:

pixelX = (dialogunitX * baseunitX) / 4
pixelY = (dialogunitY * baseunitY) / 8


Similarly, to convert from pixels to dialog units, an application applies the following formulas:

dialogunitX = (pixelX * 4) / baseunitX
dialogunitY = (pixelY * 8) / baseunitY

The multiplication is performed before the division to avoid rounding problems if base units are not divisible by 4 or 8.

You can split out the low and hi words and do the math yourself or use NUMBERMANDLL to do it for you.

[Dennis]

Thanks everybody for responding. Walt's possible solution sounds like a lot of work. To be honest I am confused by Anatoly's response. I am not using refresh anywhere and I am running LB4 on Win10. So it must be something else on my side.

Walt's explanation of ratios and scaling is probably what is happening but to solve requires a lot of work to be done lots of windows

Because of time pressure I think I will stay with what I have done (Logic and switches). A pity because dialog_modal would have really made things easier. Perhaps I should have taken more time at the start of the conversion and experimented more with dialog_modal.

A pity, but it is my bad. I need to spend time trying to resolve the software protection issues that I have than making changes to the windows I already have. 

Thanks everyone

Dennis

[Rod]

This is how the three window types Window, Dialog and Dialog_Modal look on my PC. They are not distorted. The only way I can distort the Dialog window is by issuing a refresh command. Is there more to explore?

[Brandon Parker]

This is offtopic, but I wanted to make the statement anyway based on the OP's code shown above...

First, if you are using normal branch label style and not opening windows within Subroutines then you should issue a Wait command after opening the window and prior to the first branch label. Otherwise, the program flow will run right through into the first branch label.

Now, on to the more intricate item(s).

You should NEVER EVER issue a wait command within a Subroutine/Function to prevent scoping issues. Also, if you are using Subroutines to open windows, you should switch to using Subroutines for all of the event handlers (ex. button clicks, window closing routines, ... etc.).

In the case shown above, the program would wait within the Subroutine, and while the button press routine and the window exit routine would be available in the scope, should the program exit the subroutine's scope, those branch labels will no longer be available.

If you run the code shown below and open the second window using the button, you will notice that you can then never ever get the program flow back into the subroutine where the first window's event branch labels are located.
Sub openWindow
   Button #Test1.button1,"Press Me",[pressMe], UL, 5, 5, 70, 25
   Button #Test1.button2, "Open New Window", [openNewWindow], UL, 5, 35, 100, 25
   Open "Window Test" For Window As #Test1
   #Test1 "TrapClose [quit]"
   Wait

   [pressMe]
       Print "Button Pressed!"
       Wait

   [openNewWindow]
       Call openSecondWindow
       Wait

   [quit]
       Print "Closing #Test1 Window"
       Close #Test1
       Wait
End Sub


Sub openSecondWindow
   Open "Window Test 2" For Window As #Test2
   #Test2 "TrapClose [quit2]"
   Wait

   [quit2]
       Print "Closing #Test2 Window"
       Close #Test2
       Wait
End Sub

Here is one way I might structure that type of program using Subroutines...
Global False : False = 0
Global True  : True  = 1

Call openMainWindow
Wait

   Sub openMainWindow
       Button #Main.btnPressMe,"Press Me", pressMe, UL, 5, 5, 70, 25
       Button #Main.btnOpenNew "Open New Window", openNewWindow, UL, 5, 35, 100, 25
       Open "Window Test" For Window As #Main
       #Main "TrapClose quit"
   End Sub

'_________________________________________________________________________________________________________________________________________________________
'_________________________________________________________________________________________________________________________________________________________

   Sub pressMe handle$
       Print "Button Pressed!"
   End Sub

'_________________________________________________________________________________________________________________________________________________________
'_________________________________________________________________________________________________________________________________________________________

   Sub openNewWindow handle$
       Call openSecondWindow
   End Sub

'_________________________________________________________________________________________________________________________________________________________
'_________________________________________________________________________________________________________________________________________________________

   Sub quit handle$
       If (handle$ = "#Main") And isWndOpen("#SecondWindow") Then
           Call quit "#SecondWindow" 'Or just issue Close #SecondWindow, but you won't get the Print statement
       End If
       Print "Closing ";handle$;" Window"
       Close #handle$
       If (handle$ = "#Main") Then End
   End Sub

'_________________________________________________________________________________________________________________________________________________________
'_________________________________________________________________________________________________________________________________________________________

   Sub openSecondWindow
       Open "Window Test 2" For Window As #SecondWindow
       #SecondWindow "TrapClose quit"
   End Sub

'_________________________________________________________________________________________________________________________________________________________
'_________________________________________________________________________________________________________________________________________________________

   Function isWndOpen(handle$)
       On Error GoTo [Error]
           isWndOpen = (Hwnd(#handle$) <> False)
       [Error]
   End Function


{:0)

Brandon Parker

[klewlis]

Brandon,
If you run this code, you will see that my dialog windows work exactly as I both want and expect them to. The window is not locked up and I don't understand why using wait as I have is a problem. Your "style" of coding is not the only way to solve a problem. I was not asking how to make my dialog work, just why it didn't appear in the location I was expecting it to. tsh73 actually pointed me to the information that solved my problem. The dialog window is a child window of the main window and is located within the frame of my main window.


'----- Pre-window set up
   nomainwin
   WindowWidth = 1400
   WindowHeight = 722
   UpperLeftX = int((DisplayWidth-WindowWidth)/2)
   UpperLeftY = int((DisplayHeight-WindowHeight)/2)

   MWW = 1400
   MWH = 722

   BackgroundColor$ = "lightgray"
   ForegroundColor$ = "black"
   TextboxColor$ = "white"

   global BadInfo
   global MWW
   global MWH
   dim BldgInfo(4, 10)
   dim RftrInfo(4, 1000)
   dim group(4)

'----- Calculate button moved here to make it the last control in the tabbing order
   button #main.calc0, "Calculate", [GetInfo], UL, 1120, 602, 245, 60

'----- Open main window
   open "Rafter Master" for window_nf as #main
   print #main, "font ms_sans_serif 10"
   print #main.calc0, "!font ms_sans_serif 20 bold"
   print #main, "trapclose [quit.main]"

   call instruct
   call numFormat

'----- Wait for "instant" input or calculate button to be clicked
[main.inputLoop]
   if BadInfo = 1 then
       x = 0
       y = 0
   end if
   wait

[GetInfo]
   wait

'----- End the program
[quit.main]
   close #main
   end

sub instruct
'----- Pre-window set up
   nomainwin
   WindowWidth = 550
   WindowHeight = 445
   UpperLeftX = int((MWW - WindowWidth) / 2)
   UpperLeftY = int((MWH - WindowHeight) / 2)

'----- Information to be displayed
   button #Instruct.button1,"GOT IT ",[quit.instruct], UL, 455, 380, 70, 25
   statictext #Instruct.statictext1, "ALL ROOF PITCHES MUST MATCH!   ALL WALL HEIGHTS MUST MATCH!", 5, 5, 525, 20
   statictext #Instruct.statictext2, "If there is enough interest, these features may be added at a later time", 5, 35, 450, 20
   statictext #Instruct.statictext3, "This program will calculate rafter, ridge, hip and valley lengths.", 5, 75, 490, 20
   statictext #Instruct.statictext4, "It will also calculate the following jack rafter lengths:", 5, 105, 325, 20
   statictext #Instruct.statictext5, "Ridge to Valley, Hip to Wall, Hip to Valley and Ridge to Ridge.", 5, 135, 400, 20
'    statictext #Instruct.statictext6, "When inputting measurements, the following conventions must be followed:", 5, 175, 450, 20
'    statictext #Instruct.statictext7, "Feet and inches must be separated with a dash, (e.g. 19-6).", 5, 205, 570, 20
'    statictext #Instruct.statictext8, "Foot, ('), and inch, (" + chr$(34) + "), marks are allowed, (e.g. 19'-6" + chr$(34) + "), but are not required.", 5, 235, 500, 20
'    statictext #Instruct.statictext9, "Use of the foot mark, (') does not require use of the inch mark, (e.g. 19'-6).", 5, 265, 520, 20
'    statictext #Instruct.statictext10, "Fractional inches must be separated from whole inches with a space, (e.g. 19-6 3/8).", 5, 295, 530, 20
'    statictext #Instruct.statictext11, "Decimal inches require a decimal point, (e.g. 19-6.375).", 5, 325, 450, 20
'    statictext #Instruct.statictext12, "Ridge Width must be expressed as inches only, (e.g. 1 1/2 or 1.5).", 5, 355, 450, 20
'    statictext #Instruct.statictext13, "Roof pitch must be expressed as a fraction, Rise / Run, (e.g. 6/12).", 5, 385, 450, 20

'----- Open "about" window
   open "About Rafter Master" for dialog_modal as #Instruct
   print #Instruct, "font times_new_roman 12"
   print #Instruct, "trapclose [quit.instruct]"

'----- Wait here for button click
[Instruct.inputLoop]
   wait

'----- Close "about" window
[quit.instruct]
   close #Instruct
end sub

'----- Explain measurement entry formatting
sub numFormat
'-----Pre-window set up
   nomainwin
   WindowWidth = 675
   WindowHeight = 420
   UpperLeftX = int((MWW - WindowWidth) / 2)
   UpperLeftY = int((MWH - WindowHeight) / 2)

'----- Information to display
   button #Format.button1,"GOT IT ",[quit.format], UL, 565, 340, 90, 35
   'statictext #Format.statictext1, "ALL ROOF PITCHES MUST MATCH!   ALL WALL HEIGHTS MUST MATCH!", 5, 5, 525, 20
   'statictext #Format.statictext2, "If there is enough interest, these features may be added at a later time", 5, 35, 450, 20
   'statictext #Format.statictext3, "This program will calculate rafter, ridge, hip and valley lengths.", 5, 75, 490, 20
   'statictext #Format.statictext4, "It will also calculate the following jack rafter lengths:", 5, 105, 325, 20
   'statictext #Format.statictext5, "Ridge to Valley, Hip to Wall, Hip to Valley and Ridge to Ridge.", 5, 135, 400, 20
   statictext #Format.statictext6, "When inputting measurements, the following conventions must be followed:", 5, 5, 600, 30
   statictext #Format.statictext7, "Feet and inches must be separated with a dash, (e.g. 19-6).", 5, 55, 670, 30
   statictext #Format.statictext8, "Foot, ('), and inch, (" + chr$(34) + "), marks are allowed, (e.g. 19'-6" + chr$(34) + "), but are not required.", 5, 105, 600, 30
   statictext #Format.statictext9, "Use of the foot mark, (') does not require use of the inch mark, (e.g. 19'-6).", 5, 155, 620, 20
   statictext #Format.statictext10, "Fractional inches must be separated from whole inches with a space, (e.g. 19-6 3/8).", 5, 205, 630, 20
   statictext #Format.statictext11, "Decimal inches require a decimal point, (e.g. 19-6.375).", 5, 255, 550, 20
   statictext #Format.statictext12, "Ridge Width must be expressed as inches only, (e.g. 1 1/2 or 1.5).", 5, 305, 550, 20
   statictext #Format.statictext13, "Roof pitch must be expressed as a fraction, Rise / Run, (e.g. 6/12).", 5, 355, 550, 20

'----- Open format window
   open "Rafter Master Format Assistant" for dialog_modal as #Format
   print #Format, "font times_new_roman 14"
   'print #Format.button1, "!font times_new_roman 12"
   print #Format, "trapclose [quit.format]"

'----- Wait for button click
[format.inputLoop]
   wait

'----- Close format window
[quit.format]
   close #Format
end sub


I have only posted the relevant code, and am not finished with it yet, yes I know the first dialog and it's font do not look pretty, I will take care of that later.

The only function of these two dialog windows is to inform the user of the programs usage, so the only thing the button does is close the window.

[klewlis]

If the program exits the subroutine before the button is pressed to close the window then something is broken and needs to be fixed. The way this is set up, this should be next to impossible.

[Chris Iverson]

Jan 11, 2022 21:41:32 GMT -5 klewlis said:

Your "style" of coding is not the only way to solve a problem.

It's not about coding style. It's about known and demonstrated issues in LB that many people have had problems with, that you're perfectly lined up to run headfirst into.

Issuing waits within subroutines has been known to cause issues with LB's internal event handling before, as has encapsulating a second window within a sub without using sub event handlers for other windows.

You may get away with it by making sure no other branch label events ever fire, as well as making sure scope never leaves the sub, but if you slip up once, your entire program will crash.


If it's working for you now, great!

But if you start having weird issues in the future, where things stop responding or start crashing on you, well, you've been warned.

[Brandon Parker]

Jan 11, 2022 21:41:32 GMT -5 klewlis said:

Your "style" of coding is not the only way to solve a problem. I was not asking how to make my dialog work

No one is forcing anyone to copy a programming style though; as Chris mentioned, it is not really about programming style in this case. It is about the inner workings of Liberty BASIC and the pitfalls that can cause issues. I agree, my "style" of programming is not what everyone wants/uses; each programmer has his/her own style that is developed over time. I simply try to make my examples easy to understand and extremely effective. Being a moderator on the forum, I also feel that I have a wanted obligation to help others where I can.

So...

In general terms, subroutines are defined as callable blocks of code that return to the calling code at the instruction immediately following the call to the subroutine (notwithstanding the ability for some languages to override the return address behavior...some can do this). The code in your initial post above, while it may work for your purpose at this time, breaks this definition by executing the "Wait" command within the subroutine.

When projects grow over time, they tend to become more complex and design changes are made. It is in this type of scenario where people get hit the hardest...years down the road with a fully functional program all of a sudden crashing due to one simple change that seemingly should not cause any issues.


Now, here is the harsh part...

I can state that my abilities and well-structured programming earned me a 4.0 in my college computer science program as well as the college's computer science award, so that is all the approval I need with respect to my "style" of programming or programming abilities.

When we are on the forum, we should just try and be respectful of others who are trying to help. Most people are not here to point fingers at others about how incorrectly they are doing something. Most people are here because they love Liberty BASIC and the things that can be accomplished very easily with the language. In my experience, those members who are rude or otherwise disparaging towards those attempting to help often find themselves lacking assistance further down the line. Most people do not want to continue to help people or point out areas for potential issues in the future when this behavior occurs. I would ask that you please show a little respect for people on the forum that are trying to provide assistance. This is the second time I have felt blatantly disrespected by you, and I could point to at least one other recent disrespectful response to another moderator as well.



We are all here just trying to help one another enjoy Liberty BASIC, so let's just get on with the enjoyment part of it all...


{:0)

Brandon Parker

[klewlis]

Brandon, 

    I was not attacking you, nowhere in your post does it say this is a known problem or pitfall with LB.  The post appeared to be a rant on my coding style. 

I do not come here expecting anyone to write code for me.  A simple "watch it, this is known to cause problems and here is why" would have been sufficient.

Then I may have asked what you meant or for an example.

Just some food for thought.