SOLVED?: moving desktop icons with eCenter

[A.D. Fundum]

Not verified with a fresh install of a system with the problem of
eCenter and icons moving towards the south.

1. There are icons near both the top left and bottom right corners of
my desktop, so it should fit. If it doesn't fit, i.e. there are moving
icons, then restoring the desired look is one mouse click away.
2. You may want to use an utility to delete the position of the
desktop. I didn't work for me at all, but it may support step 7.

3. Scroll the desktop to make sure that the scrollbar(s) disappear
4. Shutdown the machine, or reset the WPS
5. If the scrollbars appear again, then move your icon(s) and go back
to step 3

6. This step is a typical system with the problem, without scrollbars,
and without icons too close to th edge of the desktop, so most people
may skip steps 1-5. The seventh step is the magic one:

7. Shutdown... -> Restart (i.e. a warm reset)
8. No more moving icons? Backup your WPS
9. Shutdown... -> Shutdown

Tested with a desktop pc and a notebook (eCenter settings: top of
screen, reduce size of the desktop area). Solved twice, albeit the
setup of both systems is almost identical..

HTH.


--

[Doug Bissett]

Post by A.D. Fundum
Not verified with a fresh install of a system with the problem of
eCenter and icons moving towards the south.
1. There are icons near both the top left and bottom right corners of
my desktop, so it should fit. If it doesn't fit, i.e. there are moving
icons, then restoring the desired look is one mouse click away.
2. You may want to use an utility to delete the position of the
desktop. I didn't work for me at all, but it may support step 7.
3. Scroll the desktop to make sure that the scrollbar(s) disappear
4. Shutdown the machine, or reset the WPS
5. If the scrollbars appear again, then move your icon(s) and go back
to step 3
6. This step is a typical system with the problem, without scrollbars,
and without icons too close to th edge of the desktop, so most people
7. Shutdown... -> Restart (i.e. a warm reset)
8. No more moving icons? Backup your WPS
9. Shutdown... -> Shutdown
Tested with a desktop pc and a notebook (eCenter settings: top of
screen, reduce size of the desktop area). Solved twice, albeit the
setup of both systems is almost identical..
HTH.
http://hobbes.nmsu.edu/download/pub/os2/util/wps/movingdesktopobjects100.zip
http://hobbes.nmsu.edu/download/pub/os2/util/wps/fpos080.zip

to delete the Desktop (ONLY the Desktop, not the Desktop
subdirectories). There may be more than one entry. I also delete
everything other than the dedktop subdirectories, and any folder that
I have set special settings for, which helps to keep the INI files
cleaned up. All deleted folders use the default settings, if you open
them, and you can set your settings again, if you accidentally delete
something.

The trick is to get the desktop settings back to the default.
Unfortunately, they do get messed up from time to time, and you will
need to stop the icons from moving again.

HTH...

[A.D. Fundum]

Post by Doug Bissett

Post by A.D. Fundum
You may want to use an utility to delete the position of the
desktop.
didn't work for me at all

http://hobbes.nmsu.edu/download/pub/os2/util/wps/movingdesktopobjects1
00.zip

That was the utility, the one which unfortunately didn't solve it at
all, I was talking about.

Post by Doug Bissett
they do get messed up from time to time, and you will
need to stop the icons from moving again.

Again I never experienced that., once it worked using a trick which
any user can try:

Shutdown... -> Restart -> OK-button


--

[A.D. Fundum]

Post by A.D. Fundum

Post by A.D. Fundum

Post by A.D. Fundum
You may want to use an utility to delete the position of the
desktop.
didn't work for me at all

movingdesktopobjects100.zip

That was the utility, the one which unfortunately didn't
solve it at all, I was talking about.

Post by A.D. Fundum
they do get messed up from time to time, and you
will need to stop the icons from moving again.

Again I never experienced that., once it worked using a trick
Shutdown... -> Restart -> OK-button

Third system, same results. No more icons moving to the south. I also
tried "SETBOOT /D", but that didn't kickstart the magic. Nor does any
CAD-related reboot. This time the machine was an IBM ThinkPad X20,
which has to be booted cold to avoid a fatal PCMCIA-related error, so
most likely it's related to the way this specific shutdown works
and/or the changed WPS setting (restarting is sticky, you'll have to
reset it to Shutdown... -> Shutdown later).

Required steps (eCS 1.2), without any icons too close to the edges of
the desktop: cold boot, use the WPS scrollbar to restore the desired
layout and to remove the scrollbar, Shutdown... -> Restart-radio
button -> OK-button, power off before the OS is started
(X20-specific), cold boot (X20-specific). Optional: enable the OS'
WPS backup to save this situation next time, and Shutdown... ->
Shutdown to restore that setting.

If movingdesktopobjects100.zip worked for you (beyond removing an INI
file entry), then YMMV.


--

[A.D. Fundum]

Post by A.D. Fundum
movingdesktopobjects100.zip

There was another way, without using this utility, but my success rate
is 100% (6 out of 6) with:

1. Execute this utility (or the FPos equivalent)
2. Select the other Shutdown...-menu option (shutdown or restart) and
select OK

My success rate of just using this utility was 0 out of 5, or 0 out of
6..


--

[Doug Bissett]

Post by A.D. Fundum

Post by A.D. Fundum
movingdesktopobjects100.zip

There was another way, without using this utility, but my success rate
1. Execute this utility (or the FPos equivalent)
2. Select the other Shutdown...-menu option (shutdown or restart) and
select OK
My success rate of just using this utility was 0 out of 5, or 0 out of
6..

I usually use FPos, with 100% success. Perhaps you have a different
problem. I know that some time back, I tried new versions of the
eCoSoft stuff, and couldn't get rid of moving icons, until I
uninstalled that crap. Since then, I have rarely seen the problem,
except when I run CleanINI. Now, I run CleanINI, and then FPos, about
every second week, and the problem never shows up. I also use DMT,
which makes CleanINI less important.

[A.D. Fundum]

Perhaps you have a different problem.

Perhaps you have a different /additional problem, for one because I do
assume that you use/tried/know more different apps. One of my first
install actions is to move the eCenter to the top of the screen ASAP
and to reduce the size of the desktop, which triggers it (perhaps a
few lucky exceptions excluded). Just using the utility (not FPos)
never solved anything

Earlier I was able to get it right without deleting a folder's
position. Now using the utility AND changing the Shutdown...-radio
button setting AND rebooting/restarting solves it every time. The
utility didn't. I never experienced a return of this problem, unless
I'll intentionally restore a broken system setup after pressing
ALT-F1. CHECKINI is executed frequently.

As mentioned earlier the utility may be an important step, I don't
even want to deny that, but as such the utility doesn't solve it.
Solving it may require a next step. i.e. the "magic" of the
Shutdown... menu.

IIRC I used to be able to get it right without deleting a folder's
position, but I don't remember how. It had to do with playing with
the eCenter's settings and reboots.


--

[Doug Bissett]

Post by A.D. Fundum

Perhaps you have a different problem.

Perhaps you have a different /additional problem, for one because I do
assume that you use/tried/know more different apps. One of my first
install actions is to move the eCenter to the top of the screen ASAP
and to reduce the size of the desktop, which triggers it (perhaps a
few lucky exceptions excluded). Just using the utility (not FPos)
never solved anything

I always create a second eCenter bar, at the top of the screen, and I
set both to reduce the size of the desktop (which is mostly ignored by
programs). There may be some sort of compensation by doing it that
way. I always reboot after doing CleanINI, and FPos, just to be sure
that it didn't break something. Then, I reboot again, and do the
desktop archive.

Post by A.D. Fundum
Earlier I was able to get it right without deleting a folder's
position. Now using the utility AND changing the Shutdown...-radio
button setting AND rebooting/restarting solves it every time. The
utility didn't. I never experienced a return of this problem, unless
I'll intentionally restore a broken system setup after pressing
ALT-F1. CHECKINI is executed frequently.

CheckINI sometimes causes the problem, if I don't run FPos (or the
CMD) after it. I do remember that fiddling around, as you do, would
sometimes fix the problem, but not always.

Post by A.D. Fundum
As mentioned earlier the utility may be an important step, I don't
even want to deny that, but as such the utility doesn't solve it.
Solving it may require a next step. i.e. the "magic" of the
Shutdown... menu.

Yes, you must do something to get the INI files saved, before they get
refreshed with the old data.

Post by A.D. Fundum
IIRC I used to be able to get it right without deleting a folder's
position, but I don't remember how. It had to do with playing with
the eCenter's settings and reboots.

That will also work, but it seems to be a hit, and miss, procedure
(always was for me anyway). Part of the FPos thing might be that it
saves the INI files, which may actually save the new desktop locations
properly.

[A.D. Fundum]

I set both to reduce the size of the desktop (which is mostly
ignored by programs).

It's a rather new API, WinQueryDesktopWorkArea(). I'm using it when
I'm invoking gDiagramm to create graphs which should roughly match the
size of the screen/browser windows.

CheckINI sometimes causes the problem

Typically I'm experiencing the problem immediately, after the first
boot after reducing the size of the desktop. I do run CHECKINI during
installs to avoid a hanging WPS after a reboot, but I never saw it
(re)introducing the issue.

Post by A.D. Fundum
Solving it may require a next step. i.e. the "magic" of the
Shutdown... menu.

Yes, you must do something to get the INI files saved

Next time I'll try FPos. I don't remember any other setting nor
utility with the same "magic" as the final Shutdown...-step. In 1 of
the 6 cases I had to use the other utility first to make the "magic"
work. Probably a human error, I should have given that utility a try
earlier, despite of the 0% success rate,


--

[Doug Bissett]

Post by A.D. Fundum

I set both to reduce the size of the desktop (which is mostly
ignored by programs).

It's a rather new API, WinQueryDesktopWorkArea(). I'm using it when
I'm invoking gDiagramm to create graphs which should roughly match the
size of the screen/browser windows.

CheckINI sometimes causes the problem

Typically I'm experiencing the problem immediately, after the first
boot after reducing the size of the desktop. I do run CHECKINI during
installs to avoid a hanging WPS after a reboot, but I never saw it
(re)introducing the issue.

Sorry, I mistyped. I meant CleanINI. I do use CheckINI, bout every 6
months, or so, because it cleans up things that CleanINI, and FPos
leave behind.

Post by A.D. Fundum

Post by A.D. Fundum
Solving it may require a next step. i.e. the "magic" of the
Shutdown... menu.

Yes, you must do something to get the INI files saved

Next time I'll try FPos. I don't remember any other setting nor
utility with the same "magic" as the final Shutdown...-step. In 1 of
the 6 cases I had to use the other utility first to make the "magic"
work. Probably a human error, I should have given that utility a try
earlier, despite of the 0% success rate,

The shutdown, immediately after modifying the INI files, is required
to get them saved. If you wait too long, the system will overwrite the
data with the old data, and the problem won't get fixed.

[A.D. Fundum]

Post by Doug Bissett
The shutdown, immediately after modifying the INI files, is
required to get them saved. If you wait too long, the system
will overwrite the data with the old data, and the problem
won't get fixed.

Using nothing but the utility, it reported a deleted desktop position
after a reboot. By the way, maybe it'll help too to close the eCenter
before running the utility for the first time.

If a quick shutdown is important to possibly increase a success rate
of 0% indeed, then the Rexx utility could try to call Object Rexx'
SysShutDownSystem(). I should mention that I've closed all other
applications before applying the Shutdown-magic, so there wasn't any
avoidable delay:


--

/* Not tested */
CALL RxFuncAdd 'SysLoadFuncs','RexxUtil','SysLoadFuncs'
CALL SysLoadFUncs

...

error=0
IF RxFuncQuery('SysShutDownSystem')>0 THEN error=2
IF error=0 THEN error=1-SysShutDownSystem()
IF error=2 THEN SAY 'Object Rexx not in use, or REXXUTIL.DLL too old'.
IF error>0 THEN SAY 'Shutdown... -> Select other option -> OK'
EXIT

[Doug Bissett]

Post by A.D. Fundum

Post by Doug Bissett
The shutdown, immediately after modifying the INI files, is
required to get them saved. If you wait too long, the system
will overwrite the data with the old data, and the problem
won't get fixed.

Using nothing but the utility, it reported a deleted desktop position
after a reboot. By the way, maybe it'll help too to close the eCenter
before running the utility for the first time.

I never tried that.

Post by A.D. Fundum
If a quick shutdown is important to possibly increase a success rate
of 0% indeed, then the Rexx utility could try to call Object Rexx'
SysShutDownSystem(). I should mention that I've closed all other
applications before applying the Shutdown-magic, so there wasn't any
--
/* Not tested */
CALL RxFuncAdd 'SysLoadFuncs','RexxUtil','SysLoadFuncs'
CALL SysLoadFUncs
...
error=0
IF RxFuncQuery('SysShutDownSystem')>0 THEN error=2
IF error=0 THEN error=1-SysShutDownSystem()
IF error=2 THEN SAY 'Object Rexx not in use, or REXXUTIL.DLL too old'.
IF error>0 THEN SAY 'Shutdown... -> Select other option -> OK'
EXIT

I would suggest that that there should be a suitable warning, with a
needed response, before shutting down (possibly before running the
object deletion).

I didn't write the script, and I don't want to automatically reboot
after what I do, because CleanINI has a problem with what DMT does,
sometimes, and it won't run. You can discuss changes with the author
of the script, but an immediate reboot should be optional.

It seems that OS/2 refreshes the INI file data, on some sort of
schedule. If you happen to delete the desktop object, before the
desktop refresh takes place, and a refresh takes place before you get
the INI files saved, your deletion will be replaced by the refresh. If
you get the INI files saved before the refresh, your update will hold.
If you get unlucky, and the refresh takes place before the INI files
get saved, you have lost what you did. The refresh seems to be random,
from what I have seen, but it is not "often". About once a year, I
find that I need to do the deletion process again, to get it right.

[A.D. Fundum]

Post by Doug Bissett

Post by A.D. Fundum
/* Not tested */
...

I would suggest that that there should be a suitable warning

There's no need to add warnings to samples which won't work
stand-alone, for one because your Rexx Interpreter won't understand
the line with "...", which represents the rest of the code, including
or excluding as many warnings as you like.

Maybe I should have added the modification of the Shutdown...-setting
in the INI file. Lord knows, maybe it's possible to change the
setting, shutdown the system and use STARTUP.CMD to change

To be honest I did want to add a RxMessageBox()-warning already, but
that wasn't relevant, required me to think about line lengths, and
also ignores the whole point of the sample: a shutdown with Rexx, if
possible (requires Object Rexx). RXTT37beta.INF. I'm sorry if I
suggested that I was asking for a change, but IIRC the author wasn't
anonymous and can be contacted by email.

Post by Doug Bissett
I didn't write the script

I don't know why we are discussing the utility itself. It scored 0 out
of 6, is probably one of the required steps to make it work 6 out of 6
times, and is an anything but interesting step (because it works, as
such). I just pointed out how to make it work 6 out of 6 with the most
basic OS setup, without having to repair it more than once. That's
all..

Post by Doug Bissett
You can discuss changes with the author of the script,
but an immediate reboot should be optional.

Which changes?! IIRC it was just one of the steps I decribed, and as
such it works. I'm not looking for an utility which I need once, and
which replaces a few clicks of the mouse. As mentioned elsewhere, I'd
change the documentation. And it's some kind of "myth" that the script
solves ye olde problem, but that doesn't really matter. It doesn't
solve it always, albeit I believe it works for you (not counting
having to run it more than once).

Post by Doug Bissett
your deletion will be replaced by the refresh.

I haven't done it recently, but ISTR that running it more than once
learned that the location was still deleted.

Post by Doug Bissett
The refresh seems to be random, from what I have seen,
but it is not "often". About once a year, I find that I need to
do the deletion process again, to get it right.

Seems. I stick to my claim of having to fix it once, based on solid
history. As long as I'm using eCS 1.2, after getting it right
(accidently), the problem never showed its nasty face again during all
of those years (and yes, the same IBM hardware is still running).
Nothing but the deletion process never worked for me. Please note that
the utility and its approach is at least quite interesting, and my
additional Shutdown...-"magic" may not work without it (XOR Fpos).
It's not about the utility, it's about steps required to score 6 out
of 6.

FWIW, I do expect to be able to reproduce the problem with a basic
install of the OS, followed by moving the eCenter to the top of the
screen, with a reduced workarea and a default reboot to finish the
creation of the problem. Then the utility may solve it, but I do
expect that I'll have to change the Shutdown-setting.

Finally: in 5 of the 6 cases I did execute the utility quite a few
moons ago, and all it took to make it work now was the
Shutdown...-"magic". So, regarding your warning-advice, one may
shutdown ones system many moons after executing the fine utility. In
the other case I had to execute the utility first, *but* I'm not sure
if that was the first time the utility ran.

Finally/2: I don't know if any of my suggestions, like closing the
eCenter and/or shutting down after toggling a Shutdown-bit, will work.
The only thing I tested was that toggling was enough to make the
"magic" work. A specific setting isn't required., At best I'd change
the documentation of such an utility: If it doesn't work for you, then
...! The steps are easy. A nice-to-have utility isn't required. If
needed I still can restore a "broken" WPS, but I assume that isn't
required.


--

[Andreas Schnellbacher]

f'up set to c.o.o.apps.

On Mon, 21 Jul 2014 22:24:25 UTC, "A.D. Fundum"

Post by A.D. Fundum

Post by Doug Bissett
Yes, you must do something to get the INI files saved

Next time I'll try FPos. I don't remember any other setting nor
utility with the same "magic" as the final Shutdown...-step. In 1
of the 6 cases I had to use the other utility first to make the
"magic" work. Probably a human error, I should have given that
utility a try earlier, despite of the 0% success rate,

The shutdown, immediately after modifying the INI files, is required
to get them saved. If you wait too long, the system will overwrite
the data with the old data, and the problem won't get fixed.

I'm the author of RmDesktopFolderPos.cmd, which just eases the steps
Doug had described at first. I have tested it many times and it has
always worked for me. Moreover, I found out that it has no backdraws
on my systems to remove that entry on every boot or shutdown. On my
main system I don't do that, but it has helped me already 3 times
while I did it also 3 times manually as Doug has described.

My impression is also that it doesn't exactly matters when the entry
is deleted, as far as it is deleted more often as the bug happens.
That means a shutdown or WPS reset is not required after it. I don't
have deatils about it, because that is just my observation.

[A.D. Fundum]

Post by Andreas Schnellbacher
I have tested it many times and it has
always worked for me.

Here the success rate of using nothing but the utility is 0%..

Post by Andreas Schnellbacher
it has helped me already 3 times while I did it
also 3 times manually as Doug has described.

Here the need to execute it more than once is 0%, after using the
Shutdown...-"magic".

Post by Andreas Schnellbacher
That means a shutdown or WPS reset is not required
after it. I don't have deatils about it, because that i
just my observation.

Sure, as such it's not a requirement indeed, but here it increases the
success rate from 0% to 100%. With a changed Shutdown...-setting, a
WPS reset, often performed by CHECKINI, won't do).

I suggest to change the documentation., If the problem still persist,
then give the Shutdown...-"magic" a try. It may also prevent the
problem returning as often as you described.

It's probably not true that you won't notice running it afrer every
boot. It may reduce the size of free shared memory if the Object Rexx
interpreter is in use, for example, so the next Rexx app may crash
earlier.


--

[Andreas Schnellbacher]

Post by A.D. Fundum
Here the success rate of using nothing but the utility is 0%..
Here the need to execute it more than once is 0%, after using the
Shutdown...-"magic".

Man, you should really rethink your role and wording. I'm not
responsive for your maybe screwed-up system or whatever the reason is
that it doesn't work for you.

Post by A.D. Fundum

Post by Andreas Schnellbacher
That means a shutdown or WPS reset is not required after it. I
don't have details about it, because that i just my observation.

Sure, as such it's not a requirement indeed, but here it increases
the success rate from 0% to 100%. With a changed
Shutdown...-setting, a WPS reset, often performed by CHECKINI, won't
do).

I don't believe that the relevant ini entry is always(!) recreated on
your system. Just install a new clean system and try it out. After
that, we could talk about reproducibility.

Post by A.D. Fundum
I suggest to change the documentation., If the problem still
persist, then give the Shutdown...-"magic" a try. It may also
prevent the problem returning as often as you described.

I don't see the need to advance the version number just for to add
that to the docs. That would be pointless for people.

(Chances are not too bad that I don't understand you completely.
This is not the first thread where that happens. I have answered to
how it sounds to me.)

[A.D. Fundum]

Post by Andreas Schnellbacher
I don't believe that the relevant ini entry is always(!)
recreated on your system.

IRL this "not always" is never, but your utility is irrelevant. You
can keep making up possible problems with all of my systems and you
don't have to improve your apps, but all I was pointing out is that my
steps will at least match, and improve, the results.

Post by Andreas Schnellbacher
Just install a new clean system and try it out. After
that, we could talk about reproducibility.

My already reproduced steps have nothing to do with whatever weird
condition you're trying to add now. You haven't even tried to find out
any INI file difference, if any.

Post by Andreas Schnellbacher
I don't see the need to advance the version number just for to
add that to the docs. That would be pointless for people.

I'm not sure an improvement from a possible 0 out of 6 to 6 out of 6
is pointless to users, but apparently you think it is. But you are
still overlooking that I was POSTING a solution here, instead of
REQUESTING some change. Your utility may not even be required, because
in the past was able to (accidently) fix it without it. Initially I
didn't even mention your specific utility.

Post by Andreas Schnellbacher
I don't understand you completely.

Obviously, but I'll help to not make up problems then. And face the
fact that your utility doesn't solve the problem. I wasn't discussing
your utility. I wasn't attacking your utility. Don't make up
conditions I should suddenly meet.. Don't make up problems with (all
of) my systems. Try asking questions if you don't understand
something. Don't bother me with claiming that documenting an improved
solution is just pointlessly bumping up a version number. I'll try to
care less. Again, I was POSTING a solution here (and a few other
newsgroups you've suddenly deleted). Bark up the right tree if you
want to discuss an utility which you probably aren't going to improve.
Thank you for writing the utility. And thank you for mentioning that
you don't understand me completely, but next time don't try to fill in
the gaps you think I left behind. And yes, I really hoped your final
version of the utility would because I don't remember how to fix it
without any utility.

Finally the honest suggestion to change the documentation wasn't the
industry's insult of changing the documentation instead of broken
software. Based on the assumption that my steps have to be executed
just once, I think it's pretty useless to make an utility which
toggles a simple setting twice. That's why I POSTED a (better)
solution here, instead of relying on you to release a so-called
"pointless" version. So far nobody challenged my solution (without
making up problems or checking anything, that is), so it'll be solved.
Just th eutility didn't solve it.


--

[Doug Bissett]

On Tue, 22 Jul 2014 22:31:18 UTC, Andreas Schnellbacher

Post by Andreas Schnellbacher
f'up set to c.o.o.apps.

On Mon, 21 Jul 2014 22:24:25 UTC, "A.D. Fundum"

Post by A.D. Fundum

Post by Doug Bissett
Yes, you must do something to get the INI files saved

Next time I'll try FPos. I don't remember any other setting nor
utility with the same "magic" as the final Shutdown...-step. In 1
of the 6 cases I had to use the other utility first to make the
"magic" work. Probably a human error, I should have given that
utility a try earlier, despite of the 0% success rate,

The shutdown, immediately after modifying the INI files, is required
to get them saved. If you wait too long, the system will overwrite
the data with the old data, and the problem won't get fixed.

I'm the author of RmDesktopFolderPos.cmd, which just eases the steps
Doug had described at first. I have tested it many times and it has
always worked for me. Moreover, I found out that it has no backdraws
on my systems to remove that entry on every boot or shutdown. On my
main system I don't do that, but it has helped me already 3 times
while I did it also 3 times manually as Doug has described.

I haven't tried it, but will your program run before the WPS starts?
That should be 100%, every time. I think it is actually something that
DMT should do.

Post by Andreas Schnellbacher
My impression is also that it doesn't exactly matters when the entry
is deleted, as far as it is deleted more often as the bug happens.
That means a shutdown or WPS reset is not required after it. I don't
have deatils about it, because that is just my observation.

I think there is a short period of time where it can be restored to
the old (wrong) settings. I have seen FPos fail a few times, but it is
pretty rare. That could be because it takes longer to get the desktop
object removed, and the INI save done, than what your program takes.

I wonder if RmDesktopFolderPos.cmd should be a shutdown item? I may
give that a try.

I also think that A. D. F. has some program that is triggering the
problem, or he has something that is preventing saving the change.

[A.D. Fundum]

has some program that is triggering the problem

Not counting eCenter, which triggers the problem.

You may think that, you may know that it isn't true (for one it's more
likely that you used and tried more apps, looking at your track record
of mentioning apps and solutions), and we shouldn't keep ignoring the
fact that the additional step, unlike the fine utility, did solve it 6
out of 6 times.

or he has something that is preventing saving the change.

I don't know what "the" change is. Ignoring semantics, that also
cannot be true, because the toggled Shutdown-setting is, of course,
saved. And the utility does continue to report that it cannot find a
stored position anymore. This thread-drift doesn't really matter,
because 6 out of 6 still is better than 0 (upto and hopefully
including 6) out of 6.


--

[A.D. Fundum]

Post by Doug Bissett
will your program run before the WPS starts?

FWIW: Rexx' SysIni() uses "PM facilities". A real *.EXE, i.e. not a
tokenized Rexx app, will use the same OS APIs.

Post by Doug Bissett
That should be 100%, every time.

Certainly not if 100% means that the location of the desktop is
deleted, because then my score still remains 0% instead of 100%. The
utility does its job, the utility will report every time that It
cannot find an already deleted location, but that's not enough every
time.

By the way, I cannot compare your 100% with my 100%. The final
situation may be exactly the same, but since just the utilility
doesn't work for me I have nothing to compare. If toggling your
Shutdown...-setting breaks your fixed setup, then my solution (now 6
out of 6) is about as bad as yours (0 upto and including 6 out of 6).


--

[Doug Bissett]

On Wed, 23 Jul 2014 18:48:13 UTC, "Doug Bissett"

Post by Doug Bissett
I wonder if RmDesktopFolderPos.cmd should be a shutdown item? I may
give that a try.

I have added it to the eComStation Shutdown Folder, with the RUN
parameter. So far, it has not caused any problems. Of course, it is
pretty well impossible to say that it has prevented the problem. I
suppose that if I don't see the problem for about 2 years, then I can
say that it fixed the problem.