Walkback.log Path in Windows

127 views
Skip to first unread message

Thomas Holzer

unread,
Jun 7, 2011, 4:39:56 PM6/7/11
to va-sma...@googlegroups.com

Hello,

Windows applications are not allowed to write in the Program Files directory. 

But the Walkback.log is written in the default program directory of the runtime image. As far as I understand, the walkback.log should be written in a subdirectory of the Windows Appdata directory. It can be retrieved with call SHGetFolderPath.

I think it should be the default behavior of VisualAge to write the walkbacks a configurable subdirectory of the Appdata directory. 

Maybe someone has solved this and has some code to share?

Regards

Thomas Holzer

Thomas Koschate

unread,
Jun 8, 2011, 7:50:25 AM6/8/11
to va-sma...@googlegroups.com
It's actually pretty simple to do, especially for a static file name.  If you look at EsImageStartUp, you'll find EsImageStartUp class>>walkbackFileName: for setting the default walkback name. 

We've actually extended EsImageStartUp and EsNlsImageStartUp to obtain a base walkback directory from the image .ini file, and to dump walkbacks there with file names built from the user name and time.  If you're interested, I can try to liberate that code.

Tom

Wayne Johnston

unread,
Jun 8, 2011, 1:18:20 PM6/8/11
to va-sma...@googlegroups.com
What our application has done is to run in the appdata directory, so things like a walkback.log are written there.  It works well, with most things (the .exe, .dll, nls, bitmap etc.) under Program Files.

Marten Feldtmann

unread,
Jun 9, 2011, 1:10:11 AM6/9/11
to va-sma...@googlegroups.com
Perhaps the easier way is to query the environment variable APPDATA or LOCALAPPDATA and you get the path to the directory you are allowed to write to ....

Thomas Holzer

unread,
Jun 9, 2011, 4:03:28 AM6/9/11
to va-sma...@googlegroups.com

Hi together,

thank you very much for your valuable responses.

@Tom: Yes for static files your solution is fine.

@Wayne: Yes, nice workaround! Hmm but I think there is a reason, that program files should be in the directory program files, and the application data in another directory

Unfortunately the Appdata path is different on each Windows (XP/Vista/7 and Server 2003/2008) Version. So it cannot be static hardcoded.

And I do not know how to call sHGetFolderPath: hwndOwner nFolder: nFolder              hToken: hToken dwFlags: dwFlags pszPath: pszPath to retrieve the current app data path. Anybody knows how to do this?

@Marten Yes, I tried also calling CfsDirectoryDescriptor mkdir: '%appdata%\myapppath' but this does not to work.I´m getting: EACCES (13) Invalid path or access denied [3] Any clue what is going wrong?

A plain vanilla runtime on Windows 7/Windows Server 2008 does not produce any walkback, due to the file access restriction in the Program Files directory. I´m wondering that not everybody is running in this issue.

Regards

Thomas Holzer

Marten Feldtmann

unread,
Jun 9, 2011, 5:38:42 AM6/9/11
to va-sma...@googlegroups.com
I think, that no replacement are done in these calls, because a simple

CfsDirectoryDescriptor mkdir:  ('APPDATA' abtScanEnv),'\myapppath'

works ....

Wayne Johnston

unread,
Jun 9, 2011, 7:06:06 AM6/9/11
to va-sma...@googlegroups.com
Thomas, our code doesn't have to figure out APPDATA etc.  Instead, our application is installed with the .exe etc. in Program Files, and some other things in APPDATA.  Then the Windows shortcut that runs our UI app specifies the "Start in" directory somewhere under APPDATA.  

Thomas Holzer

unread,
Jun 10, 2011, 3:51:49 AM6/10/11
to va-sma...@googlegroups.com

Marten, thank you. That works well for me!

@Instantiations Would be nice if you could create a configurable build in solution for this. Because I think changing the Kernel App is not a good style...

Greetings Thomas

 

Thomas Holzer

unread,
Jun 10, 2011, 3:53:35 AM6/10/11
to va-sma...@googlegroups.com

Wayne, thank you, good point. But we can not tell all our customers how to start our app.

Fortunately I found a solution form Martens post.

Greetings Thomas

Reply all
Reply to author
Forward
0 new messages