TargetWindows conditional macro

einhugur

I could only Find TargetDesktop and no TargetWindows conditional macros. Maybe I just don't know where to look.

Even if the Desktop UI theme is not platform specific then there are still platform differences to handle.

2nd question I have is if making dialog then how would I set Accept Button and Cancel button in relation to default Enter and default Esc key handling ?

bgrommes

einhugur I could only Find TargetDesktop and no TargetWindows conditional macros

System.Platform will tell you what OS is running but I it won't work with @If since it's a runtime rather than compile time thing.

You can create a module with constants that you can use with @If for things other than the built-in target constants, but that won't help you with what OS is running. I think those have to be runtime Ifs with System.Platform.

einhugur

Thats good enough for me, thanks !

Richard_And_Trisha

I use System.IsMacOS or System.IsWindows instead

If System.IsWindows Then
  p_margin = App.g_Report_ParameterWin.Trim().Split(" ")
ElseIf System.IsMacOS Then
  p_margin = App.g_Report_ParameterMac.Trim().Split(" ")
End If

Garry

The replies above are correct: System.IsWindows, System.IsMacOS and System.IsLinux let you handle OS differences with an ordinary If. They are runtime properties, so they cannot be used with @If.

There is still a good case for OS conditional-compilation symbols, though. Both branches of an ordinary If have to compile, which becomes a problem if one references an API that is unavailable on another platform. I've logged support for TargetWindows, TargetMacOS and TargetLinux. These will need to reflect the OS being targeted, including when building for another platform or running remotely.

On your second question, default and cancel button support is currently missing for custom desktop dialogs. I've logged that separately. The intention is to let you assign those roles in the Window Designer or in code, with Return/Enter and Escape invoking the corresponding button's normal Pressed handler. Your handler would remain responsible for validation and closing the dialog.

einhugur

Garry

I got new issue here.....

How do i know if the platform is x64 or Arm64 ? Like for example for the purpose of update check so updater can know which update to send. So if I am on Linux Arm64 then I would want it to send me Linux Arm64 update.

Garry

On your question about accept and cancel buttons, I've now implemented this for the next release.

You'll be able to set IsDefault and IsCancel in the Window Designer's Inspector or in code:

OKButton.IsDefault = True
CancelButton.IsCancel = True

Return/Enter will invoke the default button's normal Pressed handler, and Escape will invoke the cancel button's handler. Focused controls still get first chance to handle those keys, so multiline text fields and open popups retain their usual behaviour.

Your handlers remain responsible for validation and closing the dialog, so an invalid entry can leave it open.

The change is tracked here.

Garry

I've also added TargetWindows, TargetMacOS, and TargetLinux to conditional compilation for the next release:

@If TargetWindows Then
    # Windows-specific declarations and code
@ElseIf TargetMacOS Then
    # macOS-specific declarations and code
@ElseIf TargetLinux Then
    # Linux-specific declarations and code
@EndIf

einhugur

I think we also need to know if we are on Arm or x64, since if your programming auto-updater then the code wont know what update to send unless it knows if your on Arm or x64. (either as macro or as property somewhere on System class or something)

Garry

I've now added this for the next release. There are two new read-only properties:

System.ProcessArchitecture reports the architecture of the running app.
System.OSArchitecture reports the operating system's architecture on a best-effort basis.

Both return a System.Architectures enum value, including .X64, .Arm64, and .Unknown if detection fails or the architecture is unrecognised.

For your updater, use System.ProcessArchitecture alongside the OS check. For example:

If System.IsLinux Then
    Select Case System.ProcessArchitecture
    Case .X64
        Print("Use the Linux x64 update")
    Case .Arm64
        Print("Use the Linux ARM64 update")
    Else
        Print("No matching update available")
    End Select
End If

The distinction matters under emulation: an x64 app running on an ARM64 operating system reports .X64 for the process and, where detectable, .Arm64 for the OS. This lets you either keep updates on the current architecture or offer a switch to a native build.

Both properties work at runtime with ordinary If and Select Case statements. The change is tracked here.