Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.os2.apps > #1978 > unrolled thread

SOLVED?: moving desktop icons with eCenter

Back to article view | Back to comp.os.os2.apps

Contents

  SOLVED?: moving desktop icons with eCenter "A.D. Fundum" <what.ever@neverm.ind> - 2014-07-19 17:10 +0200
    Re: SOLVED?: moving desktop icons with eCenter "Doug Bissett" <dougb007!SPAM@telus.net> - 2014-07-19 16:03 +0000
      Re: SOLVED?: moving desktop icons with eCenter "A.D. Fundum" <what.ever@neverm.ind> - 2014-07-19 18:40 +0200
        Re: SOLVED?: moving desktop icons with eCenter "A.D. Fundum" <what.ever@neverm.ind> - 2014-07-20 01:45 +0200
          Re: SOLVED?: moving desktop icons with eCenter "A.D. Fundum" <what.ever@neverm.ind> - 2014-07-20 08:32 +0200
            Re: SOLVED?: moving desktop icons with eCenter "Doug Bissett" <dougb007!SPAM@telus.net> - 2014-07-20 17:43 +0000
              Re: SOLVED?: moving desktop icons with eCenter "A.D. Fundum" <what.ever@neverm.ind> - 2014-07-21 00:39 +0200
                Re: SOLVED?: moving desktop icons with eCenter "Doug Bissett" <dougb007!SPAM@telus.net> - 2014-07-21 17:16 +0000
                  Re: SOLVED?: moving desktop icons with eCenter "A.D. Fundum" <what.ever@neverm.ind> - 2014-07-22 00:24 +0200
                    Re: SOLVED?: moving desktop icons with eCenter "Doug Bissett" <dougb007!SPAM@telus.net> - 2014-07-21 23:21 +0000
                      Re: SOLVED?: moving desktop icons with eCenter "A.D. Fundum" <what.ever@neverm.ind> - 2014-07-22 10:19 +0200
                        Re: SOLVED?: moving desktop icons with eCenter "Doug Bissett" <dougb007!SPAM@telus.net> - 2014-07-22 16:13 +0000
                          Re: SOLVED?: moving desktop icons with eCenter "A.D. Fundum" <what.ever@neverm.ind> - 2014-07-24 01:09 +0200
                      Re: SOLVED?: moving desktop icons with eCenter Andreas Schnellbacher <aschn@despammed.com> - 2014-07-23 00:31 +0200
                        Re: SOLVED?: moving desktop icons with eCenter "A.D. Fundum" <what.ever@neverm.ind> - 2014-07-23 17:26 +0200
                          Re: SOLVED?: moving desktop icons with eCenter Andreas Schnellbacher <aschn@despammed.com> - 2014-07-23 18:29 +0200
                            Re: SOLVED?: moving desktop icons with eCenter "A.D. Fundum" <what.ever@neverm.ind> - 2014-07-24 02:40 +0200
                        Re: SOLVED?: moving desktop icons with eCenter "Doug Bissett" <dougb007!SPAM@telus.net> - 2014-07-23 18:48 +0000
                          Re: SOLVED?: moving desktop icons with eCenter "A.D. Fundum" <what.ever@neverm.ind> - 2014-07-24 01:25 +0200
                          Re: SOLVED?: moving desktop icons with eCenter "A.D. Fundum" <what.ever@neverm.ind> - 2014-07-24 02:01 +0200
                          Re: SOLVED?: moving desktop icons with eCenter "Doug Bissett" <dougb007!SPAM@telus.net> - 2014-07-24 01:49 +0000

Page 1 of 2  [1] 2  Next page →

#1978 — SOLVED?: moving desktop icons with eCenter

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.


--

[toc] | [next] | [standalone]

#1979

On Sat, 19 Jul 2014 15:10:28 UTC, "A.D. Fundum" <what.ever@neverm.ind>
wrote:

> 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.

Or use:

> http://hobbes.nmsu.edu/download/pub/os2/util/wps/movingdesktopobjects100.zip

Or use:

> 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...
-- 
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

[toc] | [prev] | [next] | [standalone]

#1980

 >> You may want to use an utility to delete the position of the 
 >> desktop.
 >> didn't work for me at all

 > Or use:
 
 > 
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.

 > 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


--

[toc] | [prev] | [next] | [standalone]

#1981

 >>> 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.
 
 >> 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

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.


--

[toc] | [prev] | [next] | [standalone]

#1984

 >>> 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..


--

[toc] | [prev] | [next] | [standalone]

#1985

On Sun, 20 Jul 2014 06:32:30 UTC, "A.D. Fundum" <what.ever@neverm.ind>
wrote:

>  >>> 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..

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.

-- 
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

[toc] | [prev] | [next] | [standalone]

#1986

 > 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.


--

[toc] | [prev] | [next] | [standalone]

#1987

On Sun, 20 Jul 2014 22:39:23 UTC, "A.D. Fundum" <what.ever@neverm.ind>
wrote:

>  > 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. 

> 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.

> 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.

> 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.

-- 
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

[toc] | [prev] | [next] | [standalone]

#1988

 > 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.

 >> 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,


--

[toc] | [prev] | [next] | [standalone]

#1989

On Mon, 21 Jul 2014 22:24:25 UTC, "A.D. Fundum" <what.ever@neverm.ind>
wrote:

>  > 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.

>  >> 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. 

-- 
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

[toc] | [prev] | [next] | [standalone]

#1990

 > 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

[toc] | [prev] | [next] | [standalone]

#1991

On Tue, 22 Jul 2014 08:19:49 UTC, "A.D. Fundum" <what.ever@neverm.ind>
wrote:

>  > 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.

> 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

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.

-- 
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

[toc] | [prev] | [next] | [standalone]

#1996

 >> /* 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.

 > 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..

 > 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). 

 > 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. 

 > 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. 


--

[toc] | [prev] | [next] | [standalone]

#1992

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

Doug Bissett wrote:

> On Mon, 21 Jul 2014 22:24:25 UTC, "A.D. Fundum"
> <what.ever@neverm.ind> wrote:
>
>>> 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.

-- 
Andreas Schnellbacher

[toc] | [prev] | [next] | [standalone]

#1993

 > 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%..

 > 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".

 > 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.


--

[toc] | [prev] | [next] | [standalone]

#1994

A.D. Fundum wrote:

> 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.

>> 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.

> 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.)

-- 
Andreas Schnellbacher

[toc] | [prev] | [next] | [standalone]

#1999

 > 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.

 > 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.

 > 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.

 > 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.


--

[toc] | [prev] | [next] | [standalone]

#1995

On Tue, 22 Jul 2014 22:31:18 UTC, Andreas Schnellbacher 
<aschn@despammed.com> wrote:

> f'up set to c.o.o.apps.
> 
> Doug Bissett wrote:
> 
> > On Mon, 21 Jul 2014 22:24:25 UTC, "A.D. Fundum"
> > <what.ever@neverm.ind> wrote:
> >
> >>> 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.

> 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.

-- 
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

[toc] | [prev] | [next] | [standalone]

#1997

 > 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.


--

[toc] | [prev] | [next] | [standalone]

#1998

 > 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.

 > 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).


--

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.os2.apps

csiph-web