using str for integers in MsgBox is irritating

Being a new Xojo user, I am now irritated with having to convert all the integers to str for MsgBox.

So I decided to create a Method in a Global Module :

mbx(ParamArray mTxt as Variant)
  dim msTX as string = ""
  for msCntr as integer = 0 to ubound(mTxt)
    msTX = msTX + str(mTxt(msCntr))
    if msCntr <> ubound(mTxt) then
      if str(mTxt(msCntr)) <> EndOfLine and  str(mTxt(msCntr + 1)) <> EndOfLine then msTX = msTX + " "
    end if
  next
  msgbox msTX

and then in my code just pass all the data to display on the msgbox :

mbx ("abc","123",EndOfLine,"Owner Handle =",OwnerHandle,EndOfLine,1234)

seems to work for basic MsgBox needs.

I suppose I could use the first array element to pass the type of icon to display, etc.

This seems a larger irritant - just my opinion.

I know where you are coming from, I used VB for a long time and enjoying the “type coercion” where you could pass a number and it would be converted into a string automatically. VB and REAL/Xojo are RAD tools so why not make it easier?

But, as you program longer, you start understanding what “types” are and how they help you in programming. Many programs - think PERL - are designed to do away with as much pre-knowledge as possible and just allow you to write code without remember supplementary details like “what type is this variable”?

All “types” are is a little piece of information that travels with a variable that dictates how it should be used. As languages like PERL prove, such information is not intrinsically important to the programmer, that is if you have functions that accept ANYTHING and do the conversions within themselves. Although remember this sort of thing slows down a program, it still makes things easier.

However: having a type-strict language becomes it’s own advantage. It promotes discipline by catching errors in your codes whereas a type-tolerant language doesn’t. After you program for awhile, who start learning you make a lot more mistakes than you think you do. And a type-strict language doesn’t let you pass a number when a string is needed, and that’s GOOD because sometimes you make a mistake and then the compiler won’t compile your code.

I’ve got Str() and my own function StrNum() all over my code, and sure that’s technically a waste. But you know, I’ve found it important as a disciplinary tool - and for code readability and maintenance - to be explicit when I’m using a variable as TEXT or as a NUMBER.

Sometimes a type-strict language gets annoying, like the differences between a UTF16 string on Mac as opposed to Windows (4 bytes on Mac, 2 bytes on Windows), but really, “types” can and should be used to protect yourself from yourself.

If you want to talk about type-strict… SWIFT … requires typecasting to coerce one type to another

but what it does have that I find “really cool” is a kind of “printusing” feature

var x as Int=3
var y as Double=2.5
var z as String="Test"
var s as String="This has \\(x) and \\(y) and \\(z)"
println(s)

results in

[quote=186324:@Garth Hjelte]This seems a larger irritant - just my opinion.

I know where you are coming from, I used VB for a long time and enjoying the “type coercion” where you could pass a number and it would be converted into a string automatically. VB and REAL/Xojo are RAD tools so why not make it easier?[/quote]

Thanks for the opinion Garth.

Yes, I agree that the VB features allowed a bit more leeway and forgave a bit more ‘sloppy’ coding - and I simply got used to being ‘allowed’ to do it that way.

And yes, the ‘correct’ thing to do is to code it properly.

But having just changed from a 15 year long ‘comfort zone’ in VB, some old habits like this are going to take a lot to change. Heck, I still keep trying to Run with F5 !

Ultimately it is a matter of opinion, but for now I think I will stick with my ‘alternate solution’ so that I can better concentrate on the other important stuff that I need to know before I can recode my VB app into Xojo.

Regards

[quote=186403:@Dave OBrien]Ultimately it is a matter of opinion, but for now I think I will stick with my ‘alternate solution’ so that I can better concentrate on the other important stuff that I need to know before I can recode my VB app into Xojo.
[/quote]

It is good to be conscious about the strongly typed nature of Xojo pass the superficial similarities with VB. I went from GWBasic to QuickBasic, then all versions of VB up tp .NET but today, I do appreciate very much Xojo for its rigor that enables construction of more robust programs.

That said, nothing wrong about a personal culture. Each of us has his own programming style and favorite techniques. That encompasses facilities like a typeless MsgBox, and since the language is flexible enough to allow it, why not ?

Most recently, when I started working in iOS, which with the new framework has lost a lot of traditional commands, I rapidly built a wrapper to find back my old favorite commands. One of them is MsgBox, since the IOSMessageBox is not quite as friendly.

and F8 for stepping thru your code. Second nature… will never go away.

We have a string extends method ToString that takes an integer as the parameter. So this:

msTX = msTX + str(mTxt(msCntr))

becomes

msTX = msTX + mTxt(msCntr).ToString

I think it’s a little easier to read but that’s more personal preference than anything else.

Function ToString(Extends i as Integer) As String return str(i) End Function

What I did at the very beginning with REALbasic was create a whole host of VB-named functions to wrap the REALbasic functions, so I didn’t have to bother learning a practically new language. (Although REALbasic and Visual Basic are just about the same.) The one I remember most is UCase and LCase that wrapped Lowercase and Uppercase. To this day I still use my wrapper functions even though REAL/Xojo may have included them already.

But your method can also cause exceptions easily. Such as

mbx("abc", 123, TextField1)

The mistake is forgetting the .Text property on TextField1, but this will compile fine. It will cause an exception when run though.

This kind of stuff is not in place to annoy you, it is to protect you from being human.

And on another note, it ought to be CStr instead of Str, since you’re showing it to the user…

And what about this one:

Sub Inc(extends byref i as integer) i = i + 1 End Sub

At first the strong-typing was super annoying, but with my latest project, it ended up saving me a lot of headaches actually. So now I appreciate it.