[NUG] *Re: API 2.0

[Jon Ogden]

> On Mar 13, 2019, at 5:13 PM, npalardy at airenet.com wrote:
>>> 
>> 
>> Yes, but I idon’thave to call Xojo.Net and the Xojo.Net socket needed to read stuff from a memory block or something.  It was a pain if I remember right.
> 
> Much of that was simply attempts to make it clear that sockets send and receive binary data not "strings" (ie textual data)
> Its why in the old socket if you expected to read "textual data" you HAD to call define encoding or you could get screwy results
> That goes back to the dual nature of string where you could use it for textual data OR binary data (chr vs chrb)
> It was handy but it also lead to all kinds of "why dont I get the text I sent" kinds of queries because the text encoding is NOT known
> 
> There really wasn't any perfect answer and the take away for everything was to go back to the dual nature - and live with all the questions (like Joe's wy are there diamonds in the Interface post)
> Trust me that was not an easy decision and is in part why it took so long to arrive at

You are correct.  Except working with memory blocks is somewhat cumbersome.  And Xojo doesn’t really have true binary or hex types.  Yes there’s the &b and &h to represent the literals but it’s not a true type.  I can’t do a Dim MyWord as Binary or Dim MyWord as Hex.  It would be nice if Xojo had real types for binary and hex and octal.  Then I could just look at the hex data coming in from a socket.  That would sometimes be quite nice.  Maybe there is a way to do that and I just haven’t figured it out...

> 
>>> Strings will still have the dual behaviour BUT for textual data will basically be what Text was - just accessed using "string" apis and methods
>>> 

Makes sense.  And I think Strings is a datatype that people are so used to as it’s been used in every single BASIC language course since the beginning of time.  And lots of languages or so much more loosely typed than Xojo and use strings, etc.  I get the problems with them though particularly when you are really dealing with hex characters like Telnet negotiation options.

>>> There are a lot of good things in the "new framework" and where possible they'll be moved to be the new underpinnings of the the framework 
>>> 
>> 
>> I agree.  But some things like Xojo.Timer.CallLater have some serious bugs that would suddenly pop up and cause crashes (particularly an iterating over a dictionary error).  Then other things like the Xojo.Net.TCPSockets were half developed.  Never had a .listen method.  Again had to read into a memory block.
> 
> Call later is used in ways that lead to bugs .. true
> But its not buggy in and of itself
> If you set a timer to do a calllater to a method on a form and before the call happens the form is closed you will get a crash
> It one of those things that used incautiously can cause problems - heck I ripped out code in the IDE that was put in by other engineers for exactly this reason - the IDE would randomly crash because of a calllater 


Yes, which is why CancelCall should be used in the Close event of the window.  No, I am talking about strange random errors that are not reproducible.  I had one that was an Exception for changing the dictionary while iterating over it.  Now, that was internal to the timer and outside my control.  Joe admitted it was a problem at one point but said he thought it was fixed.  It doesn’t usually happen but that and other things with it have happened enough that I’ve stopped using it and gone to using Karen’s SingleActionTimer class.  That’s much more reliable and has never given me one of these random bugs.  I’ve griped about this on the forums plenty but Xojo only wears good filter glasses.

> 
> Now what IS buggy is using WeakKAddressOf
> It does not check to see if the target has disappeared and do nothing if it has

Definitely.  I’ve discovered that.  Yeah, it prevents circular references but if the target has disappeared it causes an issue.  You are correct in that!

> 
>> I went and started to move things to Auto and Text and now regret it.  A pain to change it back.  I’ve been burned multiple times by the ToText method where I have data in a string that doesn’t translate to Text and an exception gets thrown.
> 
> You'd get "burned" in subtle way with string 
> If you shoved that into the UI you'd get problems or diamonds
> And no warning at all - at least an exception is catchable and you could try to do something sane
> 
> String will subtly corrupt its "textual data" in all kinds of nifty ways especially if sometimes you mix & match an encoded string and calls to ChrB
> And there's no programmatic way for you to enforce that "this is ALWAYS text" or binary data and avoid these surprises
> 
> The only way to add that kind of enforcement is to split the dual nature into - TEXT and MEMORYBLOCK
> 
> But we know how that went over
> 

Problem is it was just a very cumbersome way to do it when probably 90% of the time plain String works just fine.