Transmission Line Modelling Software

[Bjohannesen]

Originally Posted by Bjohannesen

I find it hard to actually see what I have entered for the Enclosure using several sections: Which Elements are to the Closed End, which Elements are to the Open End.

Sorry, my mistake. I now see what Closed and Open means by reading the latest replies.

Hi from
Wonderful Copenhagen

[just a guy]

I almost forgot, one last suggestion. Things would go a lot smoother if things just updated automatically without the having to click the "update" button every time you make a change.

[Keriwena]

Originally Posted by just a guy

I almost forgot, one last suggestion. Things would go a lot smoother if things just updated automatically without the having to click the "update" button every time you make a change.

I must defer. WinISD works like that, and I keep getting annoying error messages when I typo.

I think it may be even less apropos in a TL program where it's not uncommon to change several entries at once.

[Silent Screamer]

While it is possible to do that in code, it can be quite painful to implement. I go through stages where I try to do changes on the fly and other times I prefer to use a update button. The problem with real time changes is you have to spend a lot more time trying to catch errors.

For example deleting all of the data out of a box in real time will throw up one type of exception, type a letter where a number should be will throw up another, where as you use an update button it can check all of the data in one go and tell you if you have it right or wrong before it crashes anything.

Edit:
Forgot it has to check for double decimal points etc (while a decimal point is a valid entry and therefore you can't exclude it from acceptable characters, you only want the one), I have written code to check for all these things, and it can be quite handy for an application like this where you are dealing with a lot of decimal placed numbers, as you can use the same bit of code for numerous boxes.

[Silent Screamer]

Not sure if you plan to offer imperial conversion to those that don't speak native metric.... but here is a bit of code I wrote that works quite well for a two way conversion, you are most welcome to use it in your app.

Imports System.Math

Public Class Conversion

Dim Position As Integer
Dim FirstPart As Integer
Dim SecondPart As Integer
Dim ThirdPart As Integer
Const checkString As String = ".0123456789"

Public Function UnitConversion(ByRef ConvertMe As String, ByRef Metric As Boolean) As String

Dim charArray() As Char = ConvertMe.ToCharArray
Dim aBool As Boolean = False

For i = 0 To charArray.Length - 1
If CBool(InStr(checkString, charArray(i).ToString)) = False Then
If charArray(i).ToString = "/" Then
SecondPart = CInt(ConvertMe.Substring(Position, (ConvertMe.IndexOf("/") - Position)))
Position = ConvertMe.IndexOf("/") + 1
Else
FirstPart = CInt(ConvertMe.Substring(0, ConvertMe.IndexOf(charArray(i).ToString)))
Position = ConvertMe.IndexOf(charArray(i).ToString) + 1
End If
aBool = True
End If
Next

If aBool Then

Metric = False
ThirdPart = CInt(ConvertMe.Substring(Position, ConvertMe.Length - Position))
ConvertMe = CStr(Round((FirstPart + (SecondPart / ThirdPart)) * 25.4, 4))
Position = 0
FirstPart = 0
SecondPart = 0
ThirdPart = 0

Else

Metric = True
Dim Reducer As Double = CDbl(ConvertMe)
Dim Inches As Integer = CInt(Int(Reducer / 25.4)) 'Find the number of inches
Reducer -= Round(Inches * 25.4, 7) 'Subtract off the inches (out to 7 decimal points of accuracy)
Dim SixtyFourths As Integer = CInt(Int(Reducer / 0.396875)) 'Calculate the number of 64ths
Reducer -= Round(SixtyFourths * 0.396875, 7) 'Subract off the 64ths calculated
If Reducer > (0.396875 / 2) Then SixtyFourths += 1

Dim denom As Integer = 64 'The denominator starts off at 64
If CBool(SixtyFourths) Then 'If the number of 64ths is not 0 {even inches}
Do While (SixtyFourths And 1) = 0 'Do while number of SixtyFourths is even
SixtyFourths >>= 1 'Divide SixtyFourths by 2 (shift one bit to the right)
denom >>= 1 'Divide the denominator by 2
Loop
If CBool(Inches) Then
ConvertMe = String.Format("{0}-{1}/{2}", Inches, SixtyFourths, denom) 'Format inches and fraction
Else
ConvertMe = String.Format("{0}/{1}", SixtyFourths, denom) 'Format the fraction
End If
Else
ConvertMe = String.Format("{0}", Inches) 'Format inches only
End If
If Reducer <> 0 Then ConvertMe = "~" + ConvertMe

End If
Return (ConvertMe)

End Function

End Class

[just a guy]

Originally Posted by Keriwena

I must defer. WinISD works like that, and I keep getting annoying error messages when I typo.

I think it may be even less apropos in a TL program where it's not uncommon to change several entries at once.

Ok, I see what you mean, it probably shouldn't auto update every single time you type a character. But if the program auto updates every time you leave an input box, that's what I"d like to see. For example, the program could just assume that every time you leave an input box and click somewhere else, you'd like the program to click "update" for you, I don't see any need or advantage to do this manually.

When you are going through several iterations of a design trying to perfect it, just making single, small changes each time, that update button is going to get very annoying. Certainly not unmanageable but annoying nonetheless.

[Silent Screamer]

That's doable through something like "lose focus" you click away and it performs the check / update. But whether you do it in real time or after you leave the box it still needs to check the validity of the value, and have some means of fixing the value should you have it wrong.

[opc]

Originally Posted by Keriwena

I must defer. WinISD works like that, and I keep getting annoying error messages when I typo.

I think it may be even less apropos in a TL program where it's not uncommon to change several entries at once.

I'll second this... It think it's perfect just the way it is. I probably ran close to 1000 variations on two designs today, and I didn't find the button cumbersome at all.

Quite the opposite in fact... if you're making small changes, having the "Apply" button allows you to focus on the graphs and the way they change as you click the button. If it just updated after text entry you might constantly be wondering if it changed, or by how much.

Add to this the incredibly obnoxious tendency of programs like winISD to throw errors when you delete the value in a box, and I think it's not worth the trouble. My vote would be for the button to stay.

By the way, I checked a ported enclosure simulated in winISD and this program, and they agreed nicely with the same parameters in both programs. Not a guarantee, but it's a good thing.

Cheers,
Owen

[just a guy]

Originally Posted by opc

... if you're making small changes, having the "Apply" button allows you to focus on the graphs and the way they change as you click the button. If it just updated after text entry you might constantly be wondering if it changed, or by how much.

Cheers,
Owen

If you can focus on the graph while you click "update" you should be able to focus on the graph as you click ANYWHERE except the active input box (which would have the same effect, as I proposed). The only difference is it would be much easier and faster with no "update" button.

Maybe we aren't picturing the same thing, there also wouldn't be any error when you clear an input box, no changes would be applied until you left that input box.

[Mosquito]

Hi, a question about this soft
It's feasible to model a MLTL, tricking the enclosure parameters some way, like this?
Thanks
J.