• State Verified Answer
  • Replies 8 replies
  • Subscribers 18 subscribers
  • Views 517 views
  • Users 0 members are here
Options
Related

Loaded PRF into Profiler, but then unable to select debug.xml from Mac Finder: file is greyed out

warmsound
3 months ago

I've successfully loaded a PRF file (lumeoface.PRF) into the Profiler. The PRF was generated by a profiling-enabled debug build of my sideloaded app, on a Venu 3 watch. The Profiler then asks to "Open App Debug Xml file". I point it at a folder containing the lumeoface.prg.debug.xml file generated at the same time as the prg, but the file is greyed out and disabled in the Mac Finder view. I'm using SDK 7.2.1, although the problem occurs in at least one earlier SDK version. Any idea what I can try?

  • +1 3 months ago

    It seems that Garmin messed up the file filter for the 2nd open dialog. Either what they're trying to do is impossible (only allow *.debug.xml files) or they made a mistake trying to do it. (It's hard to tell, since macOS won't let the end user see what the actual file filter is.)

    Either way, there is a workaround! Right-click / option-click any greyed out file, select Rename, and the Open button will become available! You don't have to actually rename the file, but don't click away from it (other than to press Open).

    Please don't report this bug to Apple haha. I think you should report the profiler bug to Garmin tho.

    if you're wondering why the filename in my video ends with ".DEBUG.XML" (caps), it's bc I fruitlessly tried renaming the file a bunch of different ways

  • 0 3 months ago

    For my sideloaded apps, when I copy the PRG file to the watch I also copy the debug xml file to the log directory so that way I will have the right debug file to go with the PRF file that gets put into the log directory. If you keep working on your project and recompile your debug file will not match the PRF file on the watch. I just copy the whole log directory to my computer, that way when I load the PRF file the xml file it's looking for will already be highlighted.

  • 0 3 months ago in reply to andyj713

    Ok, but you understand the problem is that on a mac, you literally can't open the debug.xml file, right?

  • 0 3 months ago in reply to FlowState

    , what an amazing workaround, thank you! (How on earth did you discover that?)

    I too tried some desperate renaming (from outside the dialog), without any luck. Strangely, on the previous dialog where you pick the PRF file, even if you change the file extension on the PRF, the dialog still allows you to pick the file, so it's likely the dialog is filtering based on the file content, rather than just its name.

    I'll report this bug shortly to Garmin.

  • 0 3 months ago in reply to andyj713

    , thank you for your hint! I think I'd already read it in another thread, and it's the very reason I could be sure that I had the correct .debug.xml file, as I'd copied it to and from the watch, following your hint.

  • 0 3 months ago in reply to warmsound

    No worries! Just got lucky by trying to rename the file from the open dialog itself. Rare time I'm grateful to find a bug haha. (Searching for ways to force a filtered macOS open dialog to allow me to open any file were fruitless. In Windows you can do this by entering your own filter in the text box, such as *.* or *.prf - in this case I think it's a feature and a not a bug.)

    warmsound said:
    Strangely, on the previous dialog where you pick the PRF file, even if you change the file extension on the PRF, the dialog still allows you to pick the file, so it's likely the dialog is filtering based on the file content, rather than just its name.

    I don't think so. It seems that if you rename the PRF file from within the open PRF dialog (or elsewhere), it only remains selectable if it was selectable when you initially launched the open dialog. If you rename it to a different extension (either from the open dialog or elsewhere), close the open dialog, then re-open the open dialog, you will see that it's greyed out.

    Similarly, if a file is initially greyed out and you rename it to PRF from the open dialog, it won't become selectable until you re-open the open dialog.

    IOW, the "selectable state" of files in a filtered open dialog is cached from the time that the dialog is opened and doesn't change for as long as it stays open.

    I think it really is looking at the file extension, and I think what Garmin is trying to do on the 2nd dialog is either broken or not possible (e.g. trying to filter by either *.debug.xml or APPNAME.debug.xml.) I bet it would've worked if they filtered by *.xml. (Or just allowed the user to select any file at all.)

    I think that filtering by actual file contents would be a potential UX / performance nightmare. Imagine if you opened a folder with 100s or 1000s of files - the lag due to waiting for all the files to be scanned would be unbearable. (That's why preview thumbnails are typically cached by the OS.) If it caused the open dialog to simply freeze, that would suck, but it would also suck if happened "smoothly", in such a way that you just had to wait a long time for the right files to become available (how would the user know what's happening? it's obvious when preview thumbnails are being generated dynamically, and it's less of a problem bc it's cosmetic/secondary, as it doesn't block you from doing anything with files that don't have a thumbnail yet.)

  • 0 3 months ago in reply to FlowState

    Thanks again FlowState - all solid points which will teach me not to leap to conclusions, especially where they don't make sense given a little thought! My previous attempts to rename the file debug.xml to try and make it selectable would all have been in vain, because I wasn't re-opening the dialog in between attempts.

    I wonder what the filter is for the debug.xml step on Windows machines?

    I've now reported the issue here, so hopefully the CIQ team will be able to shed some light on this.

  • 0 3 months ago in reply to warmsound
    warmsound said:
    I wonder what the filter is for the debug.xml step on Windows machines?

    It's *.prg.debug.xml. (Derp I should've tried that immediately.) The filter for the first step is *.prf.

    So yeah it's likely that the profiler is trying to filter by prg.debug.xml on macOS, but it's simply not possible. Probably because on macOS, you're filtering by a literal extension (as opposed to a wildcard pattern), and prg.debug.xml isn't a real extension (neither Windows nor Mac would recognize an extension that contains a dot if you tried to register it)