I expect that this little app will be off to some other tool
Sad about that but it is what it is 
1 Like
Geoff Perlman it is not only ma Problem. It is connected to many users. We need a mouse event (pressed is okay) with mouse position feedback (x,y). Thatâs all folks. If there will be the mouse event in this wise, everybody will be happy. It is not even a kind of special control. It is a canvas where I can identify where the mouse was pressed. No need for Mouse Move events or mouse up event. Pressed with (x,y) feedback will fullfill all I need to convert to web 2.0. That is the point. And yes, I beleave that many users shooting in their own feets with mouse move. But with the MouseDown(X,Y) Event (or even MousPressed(x,y) ) will be no problem at all. It is still not Desktop. But I know that many people in case of IOT Systems are using exactly this events. It is comfortable, fast and stable.
The Rest is a bigger problem: IDE Linux, IDE Speed byself and Stuffs like Client Time have to be corrected.
As far as I can say: xojo is a great concept with really great capabilities. But it has to become more bug free than it is now. I know that the ressources are small but I guess there will be a way to find solutions for this Problems.
I I would have to decide I would place IOS and Android back so the main capabilities can grow and I would build a Java Module. This to be able to fire for Android really rapidly. And this I would scale back to IOS. With Build Servers so there would be no need for a local Mac. This would place xojo nearly alone in the market. And it would be the Solution where xojo would be the most independant tool for development.
So folks, have a nice weekend!
1 Like
Hopefully they will finally give us drag and drop between webListboxes
If the mouse events are gone, I have to assume all drag and drop is gone too?
Not by âcitizen developersâ. teh one i deplaned wit Web 1.0 were fro internal Lan only⊠The idea was to make maintenance/support a lot easier than having to install an app on every machine that needed it.
-karen
4 Likes
No, that doesnât necessarily follow. Drag and Drop could be implemented client-side with a minimum of communication back to the server.
How? I tried containers, but it took way to long load the window ( a 20 x 20 listbox was not usable for three minutes ). Iâve tried discovering in what row I pressed the mouse down in, but that didnât work, now thereâre no mouse events at all.
I meant Xojo might possibly be able to implement it without a lot of chatter to the server. Of course, I cannot speak for them. Iâm just saying that in my opinion it seems more attainable than MouseMove, which by itâs nature is chatty.
The point is all of you are speaking about solutions. In most cases there are no Ideas. Only xojo can implement it. You byself cannot do. You can implement your site in jscript, html5 and css and communicate with a html socket and write a clear backend software if you need mouse action events, positions of mouse events, drag and drop and little stuffs like client Date. You cannot implement it byself but you can write a JavaScript software wich is doing it and communicate with web socket with Xojo.
FWIW, this is what was done for Web 1.0 and I expect the Web 2 Drag and Drop API to be similar in that regard.
But the IDE issues with Web 1 / 2019r3.x still remain, especially on Linux. And some projects may never convert, such as those using Web Animator for example. So there is no possibility of Web 1 > 2 conversion, yet a genuine demand for Web 1 support.
This issue needs to be resolved somehow.
3 Likes
If they would want to resolve it. Listening to Geoff Perlmans Answers will get me in the direction that xojo will not.
1 Like
If Web 2 would be a new target then youâd be right. But as a replacement for Web 1? Itâs the very definition of âhalf-bakedâ ⊠
And THAT is why Web 1 should not have been removed until Web 2 was ready to take its place.
Most Xojo web users can open their Web projects and in a short time have the project converted and running in 2020r1
Anyone seen the Web 2 version of âEddieâs Electronicsâ? 
3 Likes
Itâs probably nearly impossible for the two to coexist, so a decision had to be made.
4 Likes
Correct.
2 Likes
xojo cloud support now only web 2 ? (just a question)
No, it supports both. The two frameworks could not coexist in Xojo (without using something like a namespace which we know users donât like). With Xojo Cloud you are dealing with separate binaries so supporting both is not a problem. Though stand alone apps that are deployed to Xojo Cloud with 2020r1 are better than the CGI support from Web Framework 1.0.
4 Likes
They could coexist with switching between the frameworks so developer can vote the framework he want to use. I see there is no problem with two frameworks. But it would mean to maintain two frameworks in one xojo version which is really expensive. I can understand the decision of xojo not to do it. What I can not understand is the way they done it. That was the fundamental point for this Posting: if there would be a release structure where Beta is Beta and the functionality would be sorted between citizen developers (let me say a high value of developers in xojo environment) and professional software developers there would be a way to do the job different. Within getting out a pro release you can write in this release all the functionality. It has not to brought out in the ide, add handler is enough as possibility.
After all there is a non Pro Release where all what is non pro functionality will be as a functionality of Software in the IDE reachable with context menu. Click and play what is making the process much more ease. I can understand people are using it. And there will be a big market exactly for this.
In this casing there would be the pro release, maybe for 700 Bucks and the click and play release for 500 Bucks and one plattform only ideâs for 300 Bucks. Nice product placement and nice product.
Thatâs what I am praying for because I would love xojo to be a player for the future.
2 Likes
Ah right, I forgot. âJust add a switch.â Itâs so simple.
Do you realize I created the original Xojo Web edition? I kind of know what Iâm talking about on the matter. If you donât want to believe Geoff because he is (of course) biased, believe the creator who hasnât worked for the company in seven years.
Xojoâs use of the word âframeworkâ when it comes to API 1, the ânewâ Xojo framework, and API 2 is basically marketing BS. In reality, they all exist in the framework at the same time. Itâs more like one big Xojo project with all the classes existing side by side. Xojo has the ability to turn off classes based on the project type, which is how iOS is missing key features, but within the same project such a thing doesnât exist.
These âframeworksâ are not chunks of code that get loaded on demand based on developer wishes. You have to find a way to make everything coexist at the same time. As Geoff mentioned, namespacing helps with such a thing, but is not popular, and is not a magic bullet. You only need to look back at the ânewâ Xojo framework to see how well THAT went.
Unfortunately, this is how it has to be.
1 Like
Thank you Thom for that information, it is clearer for me why things canât be different (have Web 1.0 and Web 2.0 âframeworksâ at the same time).
What I donât understand is why Xojo is not a suite of apps, one for Desktop, one for Web, one for iOS, etc. We need to choose when we start Xojo in what are we going to work, is not that âjust open Xojo and when you are ready to build just select your targetâ.
My guess, Iâm sure Iâm wrong, that keep adding targets and make the classes turn off based on the project type is making the product more complex every time. Wouldnât having a Xojo core, that executes the target type depending on what we are going to work on could be practical even for updates (thinking that fixes for desktop will not need to wait for the web fixes. I understand that with the resources at hand it will not be possible to separate the product.
Sorry if this doesnât make sense, it makes more sense in my head in Spanish.