2019R2; ChrB to MemoryBlock


I’ve read the docs about MemoryBlock but am not sure if my translation is correct.

This needs to be done with MemoryBlock:

[code]Dim Byte1 as UInteger = 129
Dim Byte2 as UInteger = MessageLength
dim Message as String = “Test”
dim Data as string

Data = ChrB(Byte1) + ChrB(Byte2) + Message[/code]

Does it make sense to reimplement ChrB for this purpose only?

Thanks a lot in advance

[code]dim MB2 as new MemoryBlock(2)

MB2.Byte(0) = 129
MB2.Byte(1) = MessageLength

write MB2.StringValue(0, 2) + Message[/code]

Ok, somewhat different approach than concatting ChrB()s…
But works.

or you can ignore the deprecation warnings and just continue to use ChrB :stuck_out_tongue:

too late…
how long will those things last until remove?

At the end, it took me only some hours to walk through the code and remove deprecated things.

I appreciate API 2.0, as OOP ‘means’ better "Hello, world!".left(5) than left("Hello, world!", 5).

I would even more appreciate

"Hello, world!" left 5 // user definable operators or infix function call (Kotlin)

[quote=458688:@Hans-Norbert Gratzal]too late…
how long will those things last until remove?
the IDE uses them :slight_smile:

[quote=458688:@Hans-Norbert Gratzal]too late…
I appreciate API 2.0, as OOP ‘means’ better "Hello, world!".left(5) than left("Hello, world!", 5).
there are places and reasons that the oop style will give you the wrong result :stuck_out_tongue:


[code]dim path1 as string
dim pathpart as string

path1 = “”“C:\users\ieuser\desktop
ew folder”""
pathpart = path1 ~mid 2 left (path1 length - 1)
// ~mid could mean “change in place” or immediately
// but either way: example is correct in sayin’ “nothing is clear in this code”!

Thanks a lot for the link!

But it gets worse… in JavaScript You could use

let h = Element.style.height; // what if Element is undefined or null? or then style? // so You have to use let h = Element ? (Element.style ? Element.style.height : null) : null)

Thats why there is a proposal for

let h = Element?.style?.height

But I find even more worse (more worse???) that You cannot break easily out of the chain.
That’s the path that leads us to functional programming…
For leaving the chain of rest elements, proxy could be used.

[code]dim path1 as string
dim pathpart as string

path1 = “”“C:\users\ieuser\desktop
ew folder”""
pathpart = path1 mid= 2 left (path1 length - 1)[/code]

That should be correct; Xojo does not know about a += 1 but uses a = a + 1, correct?

Please, learn the language, you are not writing proper Xojo. And yes, +=, -=, /=, *=, ++, --, are very desired, requested, but Xojo denied those operators for us saying seniors would not understand it. How sad.

That I find offensive and wrong…


Especially since “seniors” invented it. Unless Xojo knows better than K&R. Sometimes the stands they take are so [insert description here].

I strongly disagree. The beauty of Xojo is its readable plain-language syntax and lack of cryptic junk inherited from C.

In an announcement that has stunned the computer industry, Ken Thompson, Dennis Ritchie and Brian Kernighan admitted that the Unix operating system and C programming language created by them is an elaborate April Fool’s prank kept alive for over 20 years. Speaking at the recent UnixWorld Software Development Forum, Thompson revealed the following:

"In 1969, AT&T had just terminated their work with the GE/Honeywell/AT&T Multics project. Brian and I had just started working with an early release of Pascal from Professor Nichlaus Wirth’s ETH labs in Switzerland and we were impressed with its elegant simplicity and power. Dennis had just finished reading ‘Bored of the Rings’, a hilarious National Lampoon parody of the great Tolkien ‘Lord of the Rings’ trilogy. As a lark, we decided to do parodies of the Multics environment and Pascal. Dennis and I were responsible for the operating environment. We looked at Multics and designed the new system to be as complex and cryptic as possible to maximize casual users’ frustration levels, calling it Unix as a parody of Multics, as well as other more risque allusions. Then Dennis and Brian worked on a truly warped version of Pascal, called ‘A’. When we found others were actually trying to create real programs with A, we quickly added additional cryptic features and evolved into B, BCPL and finally C. We stopped when we got a clean compile on the following syntax:


To think that modern programmers would try to use a language that allowed such a statement was beyond our comprehension! We actually thought of selling this to the Soviets to set their computer science progress back 20 or more years. Imagine our surprise when AT&T and other US corporations actually began trying to use Unix and C! It has taken them 20 years to develop enough expertise to generate even marginally useful applications using this 1960’s technological parody, but we are impressed with the tenacity (if not common sense) of the general Unix and C programmer. In any event, Brian, Dennis and I have been working exclusively in Pascal on the Apple Macintosh for the past few years and feel really guilty about the chaos, confusion

Compound assignment operators are normal operators of ANY modern language. If you write Java, Javascript, PHP, Ruby, C, C#, VB.Net, Object Pascal, Swift (that to be a bit “different” starts with = followed by the operator like =+, =-, =*…), Rust, Go, Python, Dart to name a few. If ANYONE comes from a modern language, they miss it very much. To be true, writing:

deltaOmegaAnalogDifferentiator  = deltaOmegaAnalogDifferentiator + 0.38

Seems silly for them, they will automatically try it without even checking that a language (unbelievably) lacks it, as the usual is the shortened version:

deltaOmegaAnalogDifferentiator += 0.38

It is much cleaner than an unnecessary long line.

“Beauty is in the eye of the beholder”. And the current devs eyes sees the beauty of what I expressed, they are used to.
Having Var instead of Dim is not enough to modernize a language without lambdas or local functions, generics, compound assignment operators, etc.

Not only that… Xojo doesn’t even allow a method that accepts a null parameter!

Xojo does not have Nullable Types nor Null Coalescing Operators nor Safe Call operators.

Xojo does accept methods that accept Nil (Null) parameters since they are objects. Like: obj.do(Nil)