Blog Comments

  1. CAM's Avatar
    • |
    • permalink
    I recall being 11 years old and allowed to take a sip from my father's pint on holiday. It was vile! Things have changed a bit now but I didn't touch beer again until I was 18.
    Updated 5th November 2011 at 12:46 PM by CAM (Typo-swatting)
  2. Butuz's Avatar
    • |
    • permalink
    Fantastic work Dave. Great video too!

    Butuz
  3. waynewaynegoaway's Avatar
    • |
    • permalink
  4. kobusb's Avatar
    • |
    • permalink
    I set "Application.PrintCommunication = True" and that seems to solve the problem but I have not tested it extensively i.e. turning off print communication seems to create the problem.
  5. Pico's Avatar
    • |
    • permalink
    Quote Originally Posted by kobusb
    I experienced the same problem. Interestingly it does not occur if I slowly step through the code. If I quickly step through the code then it does not properly write the footers or headers.
    Intriguing! Thanks for sharing this.

    It makes me wonder whether there is a way to mimic this effect in the code. (My first thought was to try something like DoEvents, but that doesn't work.)
  6. vikpaw's Avatar
    • |
    • permalink
    Man, we've been suffering with this for so long, it's such a pain, having to do this, and guess what, if they actually roam a lot, then you need to clear their profile from all machines just in case a slow log on or duff network, means they pick up the old local profile! Add to that the fact that we had switch user feature enabled, so you could never be sure they were logged out of everywhere, and it's a nightmare. Caused no end of issues with SIMS too, as some reports didn't want to run, well, resetting the profile seemed to help, not sure why yet.
  7. kobusb's Avatar
    • |
    • permalink
    I experienced the same problem. Interestingly it does not occur if I slowly step through the code. If I quickly step through the code then it does not properly write the footers or headers.
  8. synaesthesia's Avatar
    • |
    • permalink
    Thank you, Uraken - that made me happy to know I'm not alone and that I'm not secretly a psychopathic father!
  9. Uraken's Avatar
    • |
    • permalink
    I smiled as i read your post on what i think is now referred to as old 'school parenting', good on you stick at it and you will have two well rounded children, with manners, intelligence and common sense gifted to them by you..
  10. gerardsweeney's Avatar
    • |
    • permalink
    One possible suggestion here..

    When you created your "controlled" desktop/start menu - did you disable the shortcut tracking on the PC which you copied the shortcuts up to the shared folder?

    We found that with the out-the-box setup, you would end up with shortcuts that look like:

    c:\program files\app\app1.exe
    but was really pointing to
    \\pcname\c$\program files\app\app1.exe

    We disabled the shortcut tracking, and it worked after that.

    You can also - if memory serves - use shortcut.exe to strip the "clever" redirect out of the shortcuts.
  11. browolf's Avatar
    • |
    • permalink
    we have redirected start menus but we have constant issues with delays over the icons appearing. In the worst cases this can be 20 seconds. Even when users only have read access to the shared folders. Icons sometimes mysteriously disappear or the target ends up directed to a random machine on the network. The later really slows things down. Considering making a system to maintain local icons as that's a lot more foolproof.
  12. barney's Avatar
    • |
    • permalink
    Thank you, thank you, thank you!!!
  13. gerardsweeney's Avatar
    • |
    • permalink
    We've used what appears to be this method for a good while, but with one variation..

    The local workstation has an environment variable %WSDIRALL% which points to the location, and the GPO just points to %WSDIRALL%

    We did it this way because our environment has multiple "controlled" desktops with different applications in each room.

    Oddly enough, our IT dept balked slightly at the thought of having hundreds of GPOs so doing it this way kept us in their good grace.. And it's child's play to update the environment variable locally/remotely.

    This does of course mean we have multiple desktops/start menus, but it reduces the HD calls of "I'm trying to run appx in room123 and it isn't working" (when appx isn't in room123)

    The only slight drawbacks:

    1. Some MSIs appear to HATE having the common desktop/start menu redirected, so if we're deploying anything I tend to add a couple of lines of code which temporarily puts it back to "factory default"

    2. You need a GPO which gets applied to non-locked down PCs which puts the common start menu/desktops back to normal otherwise moving a PC out of the locked-down GPO would still leave it with the registry changed to the locked down state. If you're doing this with 7, then you need 2 since 7's normal start menu/desktops are in a different location.


    This may be the mickey-mouse method we used as I'm talking about the MACHINE level (all users) start menu/desktop.. And our method is straight-out reg hacks since the days of NT4
  14. gerardsweeney's Avatar
    • |
    • permalink
    Quote Originally Posted by TheScarfedOne
    what you could do is call a vbs script which displays a message box with a timeout in it
    Yep, that's exactly what I do - only with AutoIt instead of VB as I prefer using AutoIt

    The only problem I had was that on XP, running as a scheduled task, you were not guaranteed to see the message screen pop up because of (I believe) the restrictions applied to Task Scheduler.

    I ended up running psexec included in the same folder as my AU3. The AU3 then calls PSEXEC which would then interact with the desktop..

    A complete dog's breakfast which I would probably do completely differently nowadays if I had the time, but at least it worked (works)
  15. TheScarfedOne's Avatar
    • |
    • permalink
    Rather than directly running shutdown.exe, what you could do is call a vbs script which displays a message box with a timeout in it (I use these kind of scripts for other things - like updating Start Menus), which then calls shutdown.exe.
  16. synaesthesia's Avatar
    • |
    • permalink
    What difference is there from using normal computer keyboards? None really - same bacteria involved, in keyboard there's more places for them to harbour; so in my mind that would make tablet type devices a little better in that respect. Some of the laptops I've been working on in the last couple of weeks have certainly been home to some interesting life forms
  17. WelshWoody's Avatar
    • |
    • permalink
    This may sound a little odd but here goes. What are the hygeine issues involved with having a tablet shared amongst so many people? I know someone who works in a well know DIY chain and they have to use an antibacterial wipe on the touch screen tills inbetween users which is just changing from one person to another?
  18. gerardsweeney's Avatar
    • |
    • permalink
    What burgemaster said

    Our current scheduled shutdown is a self-written AU3 script so that the users get a countdown to abort.
    Unfortunately it doesn't appear to work on Win7 so this might be very useful if you can get a warning/cancel message..
  19. burgemaster's Avatar
    • |
    • permalink
    Could an additional task be added previous to the shutdown to display a warning / cancel message?
  20. john's Avatar
    • |
    • permalink
    Yup it is indeed, great weekend last year hope this years is just as good