Programatically determine user.config path

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

bump

There is a way to determine ir from within Xibo code, but I have no idea if you can do so via 3rd party code.

What sort if scripts are you writing? it may be something we are interested in including...

We have some people that want the displays (shrunk down versions) in the corner of their workstation screens (mostly managers wanting to see the work stats displays). These are all Windows clients. I am trying to script the following:

1 -The client sometimes 'forgets' the display size and offset settings and goes full screen to the default monitor after a reboot. A script would analyze the config at boot-up to ensure that the proper settings are maintained. This would also protect against curious users changing settings.

2 - For multi-monitor users that put the display on a non-primary monitor, whenever their screensaver kicks in, the client jumps to the primary monitor in full-screen display on return. A script would run periodically to check positioning, and move/resize the client window back to where is should be.

3 - Client needs to be easily started and stopped for the user. This one does not need the config file, and Is already working.

Since this is a non-standard usage, I would not expect the distributed systems to handle these. I will be more that happy though, to make the scripts available to anyone that wants them. I am using Auto-It for the scripts.

Just curious though. Why the extra characters on the folder name? Since it is in the user profile, there is no need to distinguish it from another user's config. Wouldn't is be simpler to just call the folder 'XiboClient'?

The configuration is all done using the default dotnet configuration module, and the settings are saved automatically by dotnet in the user profile - i don't have any control over that. I did expect a different folder structure to what you are seeing though... I.e there should be no string of characters...

1. Was a bug if the user opened the options screen, there is no known issue in restart... are all your users logging into windows with their own accounts? If Xibo is forgetting settings, this obviously needs to be fixed.

2. I've not experienced this myself, although I must admit to it not being a scenario I have tried. I don't really understand why it would do that..

3. What have you don't which is easier than clicking on the icon?

We have been thinking for sometime that perhaps we should create our own settings class and no longer use the dotnet one.

1 - The users do use their own login, but the PCs are their own, and not used by anyone else, so there is only one profile to configure. The users tell me that it is after a reboot, but it is always possible they are opening and closing the options screen and not telling me about it. Mimicking a Gump-ism, "User is what user does."

2 - It could be the client, but it might also be a screen saver that does not handle multi-monitor well enough, or it might be good ol' Windows itself. I haven't had time to dig into it. For the time being, I have them close and re-open the client. It moves back on re-open. I would like to eventually remove the manual intervention though. Most of these users are senior managers.

3 - Starting the client is a simple click on the icon, but stopping it involves giving focus to the client then doing an alt-F4 to close it. I wrote the following AutoIt script to toggle the client on and off from a single shortcut.

----- begin code -----
Global Const $MyName=StringLeft(@ScriptName, StringInStr(@ScriptName,".", 0, -1)-1) ;get just the name portion of the script/exe name
Global Const $MyMutex=$MyName & "-562E130851A445E5BB57C7879F577E24" ;name the mutex for this app
If _MutexExists($MyMutex) Then Exit ;exit if another instance of this app is running

_Toggle()

Func _Toggle()
 Local $EXEName = "XiboClient.exe"
 Local $EXEPath = _ExeLocation()
 If ProcessExists($EXEName) Then
  ProcessClose($EXEName)
 Else
  Run($EXEPath & $EXEName, $EXEPath)
 EndIf
EndFunc ;==>_Toggle

Func _ExeLocation()
 ; get the correct location to launch the client from
 Local $path = RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{562E1308-51A4-45E5-BB57-C7879F577E24}", "InstallLocation")
 If @error Then
  Return ""
 Else
  If StringRight($path, 1) <> "\" Then $path &= "\"
  Return $path
 EndIf
EndFunc ;==>_ExeLocation

Func _MutexExists($sOccurenceName)
 ;Credit goes to martin for this function
    Local $ERROR_ALREADY_EXISTS = 183, $handle, $lastError
    $sOccurenceName = StringReplace($sOccurenceName, "\", "")
    $handle = DllCall("kernel32.dll", "int", "CreateMutex", "int", 0, "long", 1, "str", $sOccurenceName)
    $lastError = DllCall("kernel32.dll", "int", "GetLastError")
    Return $lastError[0] = $ERROR_ALREADY_EXISTS
EndFunc ;==>_MutexExists
---- end code -----

#3 - Ah i see, that is neat... I will be introducing a few more options with 1.3.3 (such as mimicking the python client info screen with a possibility of pressing Q to quit), but i'll still be a way short of a single button!

I will be installing Bazaar this weekend to be able to download source. Could you direct me to where that directory is determined in the client?

I am currently running 1.2, but will be moving up as soon as 1.3 is declared stable.

Im not sure the current client has any need to go in that directory...

Perhaps this article would help, http://social.msdn.microsoft.com/forums/en-US/csharpgeneral/thread/8241e079-2514-4945-a9d5-47a4e9f2793d