Error message

[ygoe]

This is new. First time yesterday evening, second time now. I've tracked that window down to Clock64.exe as it wasn't telling me. What does it mean?

T-Clock 2.4.2 build 445 on current Windows 10

[White-Tiger]

just what it says^^ Someone (probably your AV) deleted Options.exe and thus the update checker couldn't be run.

[ygoe]

Well, then it's a bug. That file happily exists in the subdirectory of where Clock64.exe is started from. Please reopen.

[White-Tiger]

well... you've got:

misc/
Clock.exe
Clock64.exe

and inside "misc/" a Options.exe ? What happens when you execute it?

[ygoe]

Yes. This happens:

C:\Users\Yves\AppData\Local\T-Clock\misc>Options.exe
Usage:   Options.exe [option] ...
Options:
  -h
    --help
  --version
  -u[check|notify|silent]  check for updates
    --update               returns IDYES(6), IDNO(7) or IDCANCEL(2)

C:\Users\Yves\AppData\Local\T-Clock\misc>

[White-Tiger]

could you try to omit .exe

[ygoe]

Does the same, as expected. The message appeared again yesterday evening, seems to show up daily now.

[White-Tiger]

hmm.. that's quite odd...
Can you reconfigure your Left click action to say: Options->Mouse->Button Left->Action Execute command->misc/Options -u (you might also try an \ as well)

[ygoe]

This produces the same anonymous error message. As does "check now" for updates on the About tab. Wouldn't the full path of the file be necessary to start the process? Who knows what the current directory currently is, it might be anything. When I specify the full path for the mouse button click, the update dialog opens, as probably expected.

Quick update: Process Hacker says the current directory of the Clock64 process is now C:\bin. There is no Clock64.exe in there and the image path is correct.

[White-Tiger]

The working directory shouldn't be of any importance here... as T-Clock is doing the path adjustments (changes / to \ because Windows sometimes messes up) and it also detects whether the path is relative or absolute and adds itself in case it's relative (another fix for some Windows issues)

You might try to un-check and re-check T-Clock's "Start T-Clock when Windows starts" and see if it's creating it properly...
(by manually investigating your created shortcut in Startmenu->All Programs->Startup or %AppData%\Microsoft\Windows\Start Menu\Programs\Startup)

So it might be related to #59

[ygoe]

That shortcut has the correct startup path set. But I suspect T-Clock can't handle a restart of Explorer properly. Explorer recently got a bit unstable for me in that the hovering of taskbar buttons never ended. Even when the mouse cursor has left the taskbar, the last-hovered task button remained hovered and the tooltip appeared. Also there were no window previews anymore, just app/window title text tooltips. I couldn't find the offending program, it doesn't seem to be T-Clock or 7+ Taskbar Tweaker. Restarting explorer.exe helps (if I'm not into logging out and in or restarting Windows), but then T-Clock switches to the directory from where I initiated that.

Restarting T-Clock after restarting Explorer fixes the issue. It then has the initial working directory set again. But I still believe that T-Clock should be able to run properly from any working directory.

I noticed that the upgrade check wants me to downgrade from 2.4.2 to 2.1.0. Is that correct or should I check/open another issue for that?

[White-Tiger]

well T-Clock shouldn't care about the working directory... that's how I build it...
I'll try to reproduce it someday, but can't really fix it if I can't.

About the update check.. can you provide a screenshot? (or did you self-compile T-Clock?)
Btw: if you hit the "check now" button manually, It always shows your current and the latest version... that's no notify, just an information (which is why it shows both: stable and beta)

edit: ok from a quick look at it... T-Clock only sets the working directory once.. on program start (as it doesn't change it later on.. or rather "shouldn't)
So I don't know who is changing your working directory... You say it works when T-Clock is started with Windows, but doesn't if the explorer restarts and T-Clock hooks the new one?
And how do you "initiate" T-Clock?

[ygoe]

It works when starting with Windows using the provided option, and it works when starting manually through the start menu shortcut. When I restart Explorer with the following batch file, the working directory has changed to where the batch file is stored:

taskkill /f /im explorer.exe
@sleep 2
explorer.exe

Ok, I understand the update message now.

[White-Tiger]

It should be fixed now in v2.4.4
Did you, by any chance, configure new mouse actions or otherwise used T-Clock's file-browse UI just before this issue occurred?
Because I had to find out that it changes the current working directory and won't restore it even if told to (it might restore it, but it might just as well bug out)

[ygoe]

I never used T-Clock for anything else than showing the time better than Windows. Not interested in anything else. And does it have a file picker UI? Never seen that.

But yes, I know that these dialogs can change the current working directory. Which reinforces my assertion that a program must find its own code regardless of the directory it is currently working in. Normally it doesn't even have to be started in its own directory but from anywhere. That's just a basic principle. I always code my apps so that they use their own executable full path to find stuff in the installation directory. There's a number of APIs for that.

[ygoe]

BTW, as I see the 2.4.4 release, where's the static build? Is it one of the new archives? Their meaning isn't documented in the release notes.

[White-Tiger]

not in the release notes.. but on the README.md xD
But yeah, might also put a note on the release itself (I thought about it, but didn't decide yet)

And yes, there are file pickers.. (Options->Alarms and there for "Action", Options-Mouse and there if "Execute command" was chosen, Add/Edit Timer)
And T-Clock didn't care about its starting directory... that's why I didn't know there could be an issue... and if you didn't use any of the file pickers, then maybe some 3rd-party program changed the working directory... like your AV or global hooking app. Anyway, it's quite hard to track when and how it might happen, so working directories on Windows are mostly useless....