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

Groups > comp.os.os2.programmer.misc > #1406 > unrolled thread

Re: SOLVED?: moving desktop icons with eCenter

Back to article view | Back to comp.os.os2.programmer.misc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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-24 01:25 +0200
                  Re: SOLVED?: moving desktop icons with eCenter "A.D. Fundum" <what.ever@neverm.ind> - 2014-07-24 02:40 +0200

#1406 — Re: SOLVED?: moving desktop icons with eCenter

 >>> 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] | [next] | [standalone]

#1409

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

#1410

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]

#1411

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

#1412

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]

#1413

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

#1414

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]

#1415

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

#1416

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]

#1418

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

#1417

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]

#1419

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

#1420

 > 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] | [standalone]

Back to top | Article view | comp.os.os2.programmer.misc

csiph-web