there is no "update of classic controls" intended or planned at this time
@ChristianSchmitz Well, maybe the plan is to create new controls in namespace and new controls have text data type.
That would also work and not need a touch on old controls.
That would be great too. Anything is better than what we have now and was the entire point of my blog article. Three years and I'm ready to embrace new framework and it's not ready yet. I look forward to when it is.
@Norman P Which claims do you mean ?
Text vs String remember something ? :P
If we read all the posts from the beginning it will give a good indication that several XOJO clients are bothered with this, other issues raised.
ah, and at no time did I say mostly XOJO users are discontented, I said that several were unhappy.
This Text thing versus String reminds me very much of what happened with string itself since the eighties. In AppleSoft Basic, Basica or GWBasic, it was just literally a bucket of bytes.
I can't remember if Quickbasic was already Unicode aware (I believe it was not), but I know for sure there was people dismayed by Visual Basic because of that who voiced their problems with the new Chr$ which no longer addressed position in the font but rather, Unicode value.
I cannot help but to see exactly the same kind of resistances when it comes to Text vs String. As the representation of textual content gets even more abstract, some constructions that relied on a more literal representation become inadequate. That is evolution. Some programmers will get stuck in the past and in their low level workarounds, some others will embrace the new without even thinking about it.
I, for one, love the fact the for the first time, we can forget about the accented characters being made of accent+letter or directly accented differences, and obtain immediately valid comparisons. But I maybe biased by my font trade.
Personally I greatly appreciate the Text type. It is all the String -> Text conversion that is cumbersome. Keep in mind that the difficult to find bugs that the String can present are evident when converting to Text forcing one to handle it. Not always is that easy or straight forward. This will be much improved when there are new framework controls so conversions are less necessary.
When I began with RealBasic (and began to programming because I only did some programs in Basic on Apple ][e when I was young), I had headache with TextEncoding.
As far as I understand, UTF8 and UTF16 can encode all the characters of our planet? I don't understand why we continue to use other encodings, to save a few bytes ?
When I'll be the dictator of this planet, I'll oblige everybody to use only one encoding :) .
If life were so easy with the encodings....
So a nice example, which is directly from our friends of the fruit company:
Subject: Ihre Apple Store Bestellung xxxxxx wird bearbeitet
Content-type: multipart/alternative; boundary=Apple-Mail-1--981739137
Date: Mon, 29 Oct 2007 17:36:38 +0000 (GMT)
Content-type: text/HTML; charset=ISO-8859-1; format=flowed
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<title>Apple Store Auftragsbestätigung</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-16">
The mail part says that it's some ISO encoding. The html says it's utf16 which is bogus here. Unfortunately, there are so many edge cases with mails where sometimes one part of information is correct and sometimes the other part.
Xojo only sees text with defined encodings. I have this mess which I need to make sense of. That means the data needs to be analyzed and then I can do the encodings. Not the other way around.
One of my program made with Xojo is MyPopBarrier. This app read emails (only a part to be quick) and allow to erase them quickly too. The development doesn't gave me only headache, many time I wanted to burn my computer, or open my window and jump, or take a rope and put it around my neck. My app still don't read email perfectly, and will never.
@Thomas R One of my program made with Xojo is MyPopBarrier. This app read emails (only a part to be quick) and allow to erase them quickly too. The development doesn't gave me only headache, many time I wanted to burn my computer, or open my window and jump, or take a rope and put it around my neck. My app still don't read email perfectly, and will never.
Interesting. On my PC I use MailWasher, which shows you the subject lines only ( and sender ) and lets you delete straight off the server. If there is anything that has a funny looking subject it gets clobbered.
Don't burn anything! ;)
Beatrix has a good question regarding if an old framework project can be opened as a new framework project or if it will it require a rewrite. We need more information from Xojo about the Desktop and Web replacements from the old framework to the new framework to make recommendations.
@Hal G Beatrix has a good question regarding if an old framework project can be opened as a new framework project or if it will it require a rewrite. We need more information from Xojo about the Desktop and Web replacements from the old framework to the new framework to make recommendations.
Lets put some context in here because "you have to rewrite your application" sounds like "the day they release this you have to rewrite your application"
We have NO intention of requiring that
We have said this many times on this thread and others
Its why we have taken the path we have with the new framework so the old & new frameworks can co-exist in your code etc
As the new framework expands you _may_ over time end up having eventually rewritten your application as you update and enhance it
But it wont be "Today Xojo released an update to the new framework and now you must rewrite your existing applications because the old framework no longer exists"
How can I be so sure ?
Because I would have to rewrite the IDE in one shot and that's a non-starter
As the new framework UI elements come into being and evolve I expect there will be a prompt asking if you wanted UI items to be converted to new framework ones and that simply saying yes would update them to the new framework equivalents.
And if you say no they are left alone.
The whole text vs string thing reminded me of something a change management consultant once told me regarding certain people at the client project we were working on together:
I don't resist change. Change is OK as long as I can keep doing things the way I have always done them.
I don't resist change. Others can change all they want as long as I am not impacted.
... Wasn't she right. ;)
@Norman P Lets put some context in here because "you have to rewrite your application" sounds like "the day they release this you have to rewrite your application"
It is only when the old framework goes away does that becomes 100% true...
But OS and web standards evolve and if the old framework does not keep up with that while the new framework is still not complete enough to stand on it's own, we will have to keep adding new framework features to classic code making it messier and messier and eventually will still need to rewrite most of that when the new framework does mature...
To keep the in-between state manageable and less of a hassle and more transparent, things like like then auto conversion of string to text and some other stuff like folderitems between frameworks would go a LONG way.
But I know you REALLY REALLY don't want to do that...
But not doing that IMO is just going to cause it's own issues as many will simply avoid using the new framework as long as possible and the wall will be hit when you are ready to remove the old framework.
I don't like the new framework for reasons I stated previously, but if I have to use it, as a customer I expect Xojo in to make it as painless as possible during the transition if if my means more work on Xojo Inc's part... particularly given how long it is taking.
As far as I can recall, in the last 17 years I have use Xojo no big change has ever come close to being anywhere near the initially expected timeframe... and because of that, I think more thought should have gone into making it easier for us during the transition and interoperation more transparent.