[quote=436015:@Norman Palardy]sure but that will only apply to web projects because older IDE’s wont understand web 2.0 at all
most other project will be unaffected by this
API 2.0 wont be forced - but if you DO use those functions you could still open the project in an older IDE
Just the API 2.0 functions wont be available
at least thats what I would expect[/quote]
i think we are saying the same thing but from different perspectives. meaning pauls comment was made from a general statement without clarifying web framework is exception to the rule while Greg specifically went over the one way transition as it relates to web.
so now i have a question. what happens if i have a web project that i want to use in the latest version of xojo but do not agree to convert it. will it still load and run? what happens in this scenario?
My take away from memory from a couple of days ago:
Old projects will run on future versions for the foreseeable future.
You wont be forced to change to the new framework.
If you F1 or right click help on something deprecated you either wont get help on it or it’ll take you to the manual on the new version. I hope you’ll still be able to find the docs on the old stuff some how though, i.e. if you’re using an older version of xojo you’ll still need to be able to find the reference material for that on documentation.xojo.com
Any projects that use the new framework will still load in old versions of xojo, but they wont run, I think the comment went something along the lines of “you can type gibberish into the code window and it’ll still open but it wont run”, so yes, old versions of xojo will load your new projects.
[quote=436018:@Rich Hatfield]
so now i have a question. what happens if i have a web project that i want to use in the latest version of xojo but do not agree to convert it. will it still load and run? what happens in this scenario?[/quote]
No idea - but I would bet not and that the project simply doesnt get opened and updated
They’d need two versions of the web framework in whatever future version of the IDE to make that possible with 2 different layout editor configurations and … I doubt thats going to happen
api 2.0 is for “code” - whether you use it or not will be optional for a long while
it has to do with whether you use “Folderitem.Item(i as integer)” vs “FolderItem.Child(zerobasedIndex as integer)”
That sort of stuff
The IDE wont autoconvert that at all
web 2.0 is for whole web projects - I doubt you’ll have an option to stay with the old web framework when it finally ships
I expect the IDE will offer to “convert” your existing project to the new format and from then on old IDE’s will not be able to open it
If you decline the conversion then the project wont open
FWIW and for those of you who werent at the show, weve designed the new web framework so that more of the framework itself is open and extensible… so it can grow over time. Both by controls and extensions designed by us, but also by 3rd parties. Unfortunately that basically meant starting over from scratch because extensibility was an after-thought the first time around.
One thing that has been on our minds from the beginning was that we wanted your experience of creating SDK controls to be as close to ours as possible. For instance, WebFileUploader has been split into two parts, the UI and the upload engine, and our basic UI control hooks in just the same way WebSDK controls will.
I also showed an example of a custom column renderer for the new WebListBox at XDC this year. For example, adding one that renders data as links involves only about 15 lines of JavaScript code.
As I said though, all of this extensibility comes at a hefty price. Web 2.0 projects simply cannot be backward compatible. Just the same, I am excited to be working on this new and innovative approach and cant wait to see what kinds of things our customers will create!
@Greg O’Lone, it would be great if your session was also available on Youtube, but maybe Web 2.0 is not as soon as API 2.0. Although both are obviously large projects API 2.0 can be delivered in tranches, Web 2.0 & Android target seem to be all or nothing.
Which would be great and making this information available to us who were not able to attend XDC creates a lot of goodwill, positive involvement and the willingness to test and incorporate the improvements and new features in our existing projects.
Forget selling video’s, this is the way to go.
Out of curiosity, why isnt the process for 3rd partys creating web controls not exactly the same as Xojo Incs? Do Xojo Incs web controls not use the same SDK?
You mean now with the current web framework? Because the original design (before I started here) didnt even consider an SDK. When we decided we needed one in Fall 2011, we had to retrofit the framework to allow it.
This time its a different story. We had an opportunity to make web control creation significantly less painful and the nearly the same for Xojo and our users at the same time, and we took it. Some of the IDE improvements even proved so useful that theyll be available sooner than the web framework.
FWIW, the WebSDK isnt only about creating controls from scratch this time though. Its also about creating control extensions. As I said above, the uploader engine is available to anyone who wants to create an uploader skin without having to recreate the mechanics. The new listbox supports custom column types, an example of which I showed in my XDC presentation this year. Text field formatters and validators are also extendable. As development continues, we are constantly looking for ways to make it so 3rd parties can extend parts of the framework this time… while making it unlikely that youll break your (and others) projects at the same time.
[quote=436290:@Greg O’Lone]You mean now with the current web framework? Because the original design (before I started here) didnt even consider an SDK. When we decided we needed one in Fall 2011, we had to retrofit the framework to allow it.
This time its a different story. We had an opportunity to make web control creation significantly less painful and the nearly the same for Xojo and our users at the same time, and we took it. Some of the IDE improvements even proved so useful that theyll be available sooner than the web framework.
FWIW, the WebSDK isnt only about creating controls from scratch this time though. Its also about creating control extensions. As I said above, the uploader engine is available to anyone who wants to create an uploader skin without having to recreate the mechanics. The new listbox supports custom column types, an example of which I showed in my XDC presentation this year. Text field formatters and validators are also extendable. As development continues, we are constantly looking for ways to make it so 3rd parties can extend parts of the framework this time… while making it unlikely that youll break your (and others) projects at the same time.[/quote]
Sorry, I meant Web 2.0. It seems strange that Xojo would implement their Web 2.0 controls using a different method to 3rd parties. Wouldn’t it have been better to have one Web 2.0 SDK that was used both internally and externally.
For some things thats quite possible… for others, not so much. Remember, not only are our controls user facing like yours, they are also the hierarchical dependencies and underpinnings of those controls.
FWIW, most of the controls weve created this time are just like the SDK, its just that theyve been created before the first draft of SDK itself is done.
I hope Xojo isn’t going to go too overboard with this exceptions-replacing-error-codes business. Should I be expecting a “string-not-found” exception rather than getting -1, if the needle isn’t found in the haystack:
offset = haystack.IndexOf (needle)
To me, an exception should occur where there’s a definite coding error. So I hope I don’t see an exception if the remote end closes a socket unexpectedly. I’d rather get error code 102.
Otherwise I can see try/catch around every statement, which won’t help readability.
[quote=436305:@Tim Streater]
Otherwise I can see try/catch around every statement, which won’t help readability.[/quote]
Java had this issue as well as it uses exceptions for so much.
So people just got into the habit of catching everything - regardless - which is just as bad as never checking error codes.
BUT, the one thing you cannot do with exceptions is just ignore them like you can an error code.
A language can only encourage good safe coding - it cant enforce it
But it an make it harder to ignore errors
As for
offset = haystack.IndexOf (needle)
IF your code used to be something like
offset = haystack.IndexOf (needle)
if offset >= 0 then
// do a whole bunch of code with offset since we know this exists
end if
now it might look like
try
offset = haystack.IndexOf (needle)
// do a whole bunch of code with offset since we know this exists
catch oobx as OutOfBoundsException
end try
In many cases you probably can just rearrange code and skip deeply nested if’s
No, in your example returning -1 is expected (and normal) so therefore not an error and not an exception.
We don’t know exactly how they’ll change everything but a socket disconnect is an event, not an error as it’s normal. Frankly, I don’t think it should have ever been an error but it is what it is. So we’ll have to see in API 2.0.
At the end of the day API 2.0 will be an adjustment to our coding styles. Many (most?) of us have NOT been checking for Error Codes when it comes to FolderItems, Text Input/Output Streams, and Databases (despite me writing about it every year for 10 years) anyway, so they’re taking this opportunity to change the framework so that we must pay attention to error errors or the app will quit.
There will be grumbling for a (long?) while and those of us with a large code base will complain the loudest no doubt.
In the 80s I wrote a medium sized multithreaded appin C which ran under VMS on a MicroVax. It used to run 9 months at a time with no page faults over and above the 6k or so that happened at startup. It “only” ran 10 months at a time because once a year, the 250kV line that powered the site was shut down for maintenance and the 64kV backup used instead. Then another site-wide power outage 2 months later when they switched back.
The collective ‘we’ do not. I see about 2 dozen OPC (Other People’s Code) projects every year. Most have no error handling at all and most don’t even handle app.unhandledexceptions.
If its harder to miss checking for an error the likelihood everyone will check for them goes way up
The only downside to exceptions is that you can only check that you have handled things at runtime - there’s no compile time way to ask the compiler for “did I handle the exceptions that could be thrown ?” unlike java where methods have to declare what exceptions they throw so the compiler can warn you about them not being handled right then.