Voted !
I confirm this is an important feature that has been of my reasons to use WE !
It’s documented as working !
[quote=21568:@Greg Olone]Fwiw, we don’t even guarantee the order of events on the desktop. There are two challenges in this area:
The different browsers fire events in a different order from one another
The general nature of the Internet means that two requests leaving the browser at the same time may not reach the server in the same order as when they left. Websockets help with this, but
[/quote]
Greg, I meant to follow up on this earlier. One place I’ve found where the (dis)order of events is particularly frustrating is the Orientation Changed / Page Resized combo. That should really just be one event that reports the current orientation and page size, and let the server sort out whether the orientation changed. The event should be triggered by either an orientation change or a resize. I’d bet there are a few other cases where a couple or few client events sent rapid fire separately might be combined into a single logical event.
Guys you may want to give Xojo inc. a break.
From what I’ve read and been told their lead WE developer (Thom) doesn’t even work for Xojo inc. anymore.
I’m sure they’re doing the best they can and they’ll fix things in time.
So please be patient about getting bug fixes or adding new features.
It’s not that simple. There are monitors that you can rotate (for the Mac) which trigger the orientation change event. How would you know the difference between that and the user just resizing their browser to 768x1024 instead of 1024x768 ? And what if the size was exactly square?
Greg’s very capable and WE has been his top priority since he joined. He’s been largely single handedly responsible for the improvements in WE so I would not get too stressed.
FWIW, I hadn’t touched WE code in about a year. Greg was brought on so he and I could work on it together - something I was really looking forward to - but I got tasked with the new IDE work and our work on WE never really overlapped.
Hi Thom, I wasn’t aware of that thank you for sharing.
That still means Xojo inc. is short handed because the existing developers are spread even thinner now. Hopefully customers will use a little patience and try to be understanding of the situation.
Btw Thom, does this mean you’re available to do freelance work for website development?
[quote=22513:@Greg Olone]It’s not that simple. There are monitors that you can rotate (for the Mac) which trigger the orientation change event. How would you know the difference between that and the user just resizing their browser to 768x1024 instead of 1024x768 ? And what if the size was exactly square?
[/quote]
One way I’ve worked around this (hack, not shared with anyone) is monitor both the orientation events (including unimplemented monitoring of Firefox mobile) and the size changes, cache the last orientation I received, and send both to server as a custom event whenever either fires.
I’d just like to know the complete state (orientation, page size) each time there’s a resize event. On browsers where users can resize (non mobile), there typically isn’t an orientation changed event anyway.
No. I really truly hate contract work.
Shoot, didn’t see “monitors you can rotate (for the Mac)”… But still the browser fires two events, an orientation changed and a resized. When browser reports each event back to server, instead of one OC event and one resize event, report two OC/resize events with the current known state. If I reposition controls in response to both, things come out OK, if a bit flickery. If the first time I see a change in orientation, I ignore, knowing I’m going to get the second with a resize in short order (yes, check for square there), I can avoid some flicker.
When you flip a device, whether a phone, tablet or rotating Mac monitor, the OC and window resize are logically one event. Right now, that’s split into two events with no order guarantee. It makes responding to the one logical event with an appropriate layout change needlessly complicated.
What I’ve settled on is having the server ping the client in response to an OC and then rearranging things after the ping,. That usually guarantees that resized and OC events have been received that the time the client’s ack is received. Not ideal.
Thanks for your answer… Same here. LOL.
If you change your mind please post your hopefully reasonable rates on your website.
In the future I may have some WE projects I’d like converted into native tools.
You might be the best guy on the planet for this type of work 
The benefit of these types of jobs is you wouldn’t have to deal with the typical client communication distractions and headaches because you’d be replicating existing projects.
[quote=22524:@Mason Mack]If you change your mind please post your hopefully reasonable rates on your website.
In the future I may have some WE projects I’d like converted into native tools.
[/quote]
Since we’re all giving Thom unsolciited business advice, make sure you get paid up front Thom, so you don’t end up with payment via monopoly money signed by Mickey Mouse. Privacy and all that…
Getting paid up front is part of why I don’t want to do it. I took on a project a few years ago that took too long, ended up going past the birth of my daughter and I had no time remaining. Project went all FUBAR and I was paid up front. Bad situation that I never want to risk getting into again. So it’s a damned if you do, damned if you don’t issue. I’ll just stay far, far away from it.
I’m hoping to have some Xojo-related announcements next week though. If the stars align correctly.
This seems like a fairly straightforward solution to the problem.
[quote=22530:@Thom McGrath]I’m hoping to have some Xojo-related announcements next week though. If the stars align correctly.
[/quote]
Congratulations about your daughter and I hope your business ventures succeed!
Looking forward to hearing about them.
For people that don’t know how to go about getting paid from clients, it’s never a problem.
There are services that act as escrow companies holding the payment from the client before you the developer does the work. When you the developer do your job, payment is released from the escrow company. You the developer set the terms you agree to work for. For example some developers demand a certain % upfront to get started and they like to get paid in stages of completed work. Once the client agrees to the terms and deposits the money in escrow it is not the clients control to not make a payment.
[quote=22542:@Mason Mack]For people that don’t know how to go about getting paid from clients, it’s never a problem.
[/quote]
I’m pretty sure nobody was asking about that.
Oh c’mon Brad, that response wasn’t necessary.
They’re nothing major, just some stuff I created while keeping myself busy. I’ve actually got everything ready to go, I just need an SSL certificate for my website, and I’m a little short on funds at the moment.
[quote=22542:@Mason Mack]For people that don’t know how to go about getting paid from clients, it’s never a problem.
There are services that act as escrow companies holding the payment from the client before you the developer does the work. When you the developer do your job, payment is released from the escrow company. You the developer set the terms you agree to work for. For example some developers demand a certain % upfront to get started and they like to get paid in stages of completed work. Once the client agrees to the terms and deposits the money in escrow it is not the clients control to not make a payment.[/quote]
Been there done that and when you cannot get the client to agree the work is “complete” you’re still screwed.
That or it takes so long to get the agreed upon specification as to what “completed” means that you never get the work and have wasted a lot of time trying to get to that point.
But in all the years I have contracted I’ve only had 2 clients refuse to pay for services rendered (sadly for significant amounts)