Following the discussion in Issue 69997 I tested the effect of different settings of the DesktopDateTimePicker property ‘HourMode’ on the time format displayed and how it correlates with the setting of the macOS System property ‘Time Format’:
Observation: the time format in display is always conform to system settings (24-Hour Time on or off). The DesktopDateTimePicker property ‘HourMode’ settings ‘Hours12’ and ‘Hours24’ have no effect when different from the system’s ‘Time Format’ setting. This is what I would expect. The wording of the official documentation ‘Dictates how the hours will be displayed.’ and the fact that HourMode can be set in the IDE imply the opposite.
Question: If the property ‘HourMode’ cannot override the system setting, how is it then different from a read-only property?
Please have a critical look at the test setup and results shown above. Is there anything I did not understand properly or I missed out? How would you answer the question above ?
I wrote a similar control for Swift based on NSDatePicker
and this is what I did to get 12 vs 24 hour independent of the OS settings… If it can be made to work with Xojo I do not know, that I will leave up to the reader
public enum hourModes : Int {
case system
case hours12
case hours24
}
public class dsDateTimePicker : NSDatePicker,NSDatePickerCellDelegate {
public var hourMode : hourModes {
get { return zHourMode }
set { zHourMode = newValue
switch newValue {
case .system : self.locale = NSLocale.system
case .hours12 : self.locale = NSLocale(localeIdentifier: "en_US") as Locale
case .hours24 : self.locale = NSLocale(localeIdentifier: "en_GB") as Locale
}
}
}
}
So Apple’s own library allows creating a control class that displays time in a format different from the system’s setting. Means Xojo’s DateTimePicker always following the system setting is a design decision and not imposed by macOS. This is also how I understood Javier’s posts. Documentation and control implementation just don’t follow through.
The thing that irks me is that they closed and locked the ticket without indicating whether or not the plan to or have already removed the option. Are they going to let another switch stay broken like the “Include Function Names” switch?
I can’t imagine anyone considering this ticket as properly handled.
Thank you @anon72844311. I only know of the two cases here where Xojo closed and locked an issue without further comment. Two is a small batch, but what can be sniffed here is that issues that would require work Xojo does not deem beneficial to its own business interest is shut down (closed). In order to avoid stating ‘will not take care of this’, because there is no sound technical reason that could be advanced, the issue is locked without a word of explanation.
Besides the fact that this is outright rude and unprofessional in a technical community, it is evidence of how poorly Xojo manages their customer’s expectations.
It might be accurate if the ticket was about compiling and the IDE didn’t have an option to build in a different location like on a local drive. Not really sure why I’d need to write a compiler to prove why you can’t edit a project on a network share. The IDE doesn’t even get near that stage, seemingly because of the use of IsWriteable even though, from memory, this was well documented as having this issue before the IDE was rewritten.
I’m not really sure either when they try to push the bug system as a place to discuss things then lock the ticket when they don’t like people continuing the discussion. Why not just ignore it and let it run its course, maybe someone there said “oh no, not him again”.
Personally, I can see why they want the users prefs to override the apps, some people can’t read or don’t understand different clock types so defaulting to the users pref would seem the sensible thing to do. If the dev wants a clock to be in a format they specify for whatever reason, then roll their own as that will be seriously in the minority so probably isn’t worth xojo’s time to implement which is probably the reason it’s not being looked at. But as they say, change it to a feature request and forget about it. Maybe they have changed over a near leaf and aren’t leaving open ended feature requests anymore, only time will tell.
Just pop a new feature request in instead of going down the “its broken” route and see what happens with it.
I am okay with a control that is dependend on system settings. No problem with that. Blocking the discussion that predictably would lead to ‘oh then the property should be read-only and the current implementation is incompatible with intended design and documentation is also wrong. Please fix it’ by locking the thread is unacceptable.
Just pop a new feature request in instead of going down the “its broken” route and see what happens with it.
Under normal circumstances I could do that. In this case, Xojo Inc’s message is crystal clear: don’t bother us any more with that stuff. Who am I to not respecting this?
If Xojo Inc wishes to proceed with gathering evidence for fixing what’s wrong, they can read my report here at INN. I did my job
