none
Snipping Tool.....

    Question

  • I've got a new version of Win7 ultimate. Years ago, I wrote a toolbar with VS years ago and now I'm trying to load the Snipping Tool and I have problems.

    The Snipping tool is visible with Explorer. However, I cannot get the the Toolbar's file loader, which is a form of explorer, to 'see' the toolbar to load it and Im looking right at it, directory wise.

    Is there a weird file attribute or something?

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me


    • Edited by Renee Culver Thursday, February 16, 2012 12:05 PM
    Thursday, February 16, 2012 12:02 PM

Answers

  • TinTin - YES I am running from 64 bit windows, but the tashbar is built 32 bits.

    But I do not know the answer to your question. The taskbar is built in 32 bits and the tasks that  I cant see are in system32 sugesting strongly that they are 32 bit tasks.

    Let me read up. The system that I did install this on is 64 bit Win7. let me read.....

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Renee,

    My understanding of this is that on a 64-bit OS, the files in System32 are actually the 64-bit versions.  The 32-bit versions are stored in the SySWOW64 directory.  Counter-Intuitve to say the least.

    From the link I provided: "32-bit applications can access the native system directory by substituting %windir%\Sysnative for %windir%\System32".

    Good Luck navigating this rabbit hole.

    • Marked as answer by Renee Culver Friday, February 17, 2012 8:28 PM
    Friday, February 17, 2012 4:09 AM
  • The thing that currently has me locked into 32 bits for the toolbar is the interop.scripting.dll added when I added an About interface to Help.

    Renee,

    This statement puzzles me a bit.  By "an About interface"  do you mean the standard VS "About Box" template?  If so, there should be no reason for that to be adding interop.scripting.dll. 

    I believe that dll is added when you add a COM reference to "scrrun.dll" (Microsoft Scripting Runtime).  If it is the scripting runtime, I would think that you could replace whatever functionality it providing with standard components.

    • Marked as answer by Renee Culver Friday, February 17, 2012 8:33 PM
    Friday, February 17, 2012 3:22 PM
  • Hi youall

    I think I have it fixed by putting an old 32-bit version in, afterall-it's just a toolbar and the old 32 bit version sees the snippingtool.exe just fine. Since the source has not changed, more and more, this points to a microsoft bug. When I build it from the sources that work now, it no longer works. Using a old toolbar works.

    TintinMN

    I said this is a complicated toolbar. Here is the main about box written in 2005. It was one of the first vb projects I did:

     

       Private Sub AboutBox1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

            Me.Controls.Add(lbRunningDirectory)

            Me.Controls.Add(lbDataDirectory)

            lbRunningDirectory.Location = New Point(0, 56)

            lbRunningDirectory.ForeColor = Color.Red

            lbRunningDirectory.AutoEllipsis = True

            lbRunningDirectory.AutoSize = True

            lbDataDirectory.Location = New Point(0, 87)

            lbDataDirectory.ForeColor = Color.Red

            lbDataDirectory.AutoEllipsis = True

            lbDataDirectory.AutoSize = True

            Dim Application As String = System.Windows.Forms.Application.ExecutablePath

            Dim fso As Scripting.FileSystemObject

            fso = CreateObject("Scripting.FileSystemObject")

            Dim fileobject As Scripting.File = fso.GetFile(System.Windows.Forms.Application.ExecutablePath)

            lbCompiled.Text = fileobject.DateLastModified

            Me.Text = FrmToolBar.Text

            Me.lbVersion.Text = System.Windows.Forms.Application.ProductVersion

            lbRunningDirectory.Text = System.Windows.Forms.Application.ExecutablePath

            Me.lbVersion.Text = String.Format("Version {0}", My.Application.Info.Version)

            lbDataDirectory.Text = FrmToolBar.Sio.AppDataPath

            fileobject = Nothing

            fso = Nothing

        End Sub

    The scripting object was only available in 32 bits. It appears that this tool bar, unchanged from 2005 and coupled with the toolbar databases of today - do the trick.

    There is a button for the snippingbar. I do not use a standard of any Kind. I actually write software.

    Here's a snipping of the about box:


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me




    • Edited by Renee Culver Friday, February 17, 2012 8:06 PM
    • Marked as answer by Renee Culver Friday, February 17, 2012 8:19 PM
    Friday, February 17, 2012 7:37 PM

All replies

  • There is nothing weird in there, Just very simple code
    Thursday, February 16, 2012 1:03 PM
  • Not that I wrote and certainly not that I can see.

    Even though you say what you will, the toolbar FD directory doesn't see the Snippingtool. That last time I did a trick that I no longer remember. It has to be either a filter or an attribute. They are other files that I don't see. How can I see all the .exe's?

    I have a feeling that those files are attribited differently than the files I can see.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me




    Thursday, February 16, 2012 1:32 PM
  • C:\Windows\system32>attrib "snippingtool.exe"
    A            C:\Windows\system32\SnippingTool.exe

    No fancy attributes on the file.

    System32 - Users can read/execute

    Thursday, February 16, 2012 6:11 PM
  • Devon,

    I think the problem is related but.....still no gold...


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Friday, February 17, 2012 1:14 AM
  • Under no circumstandes can DIR see snippingtool.exe although Explorer can. My toolbar cannot see it either.

    By the way, although I dont see how it's relevant, I use MSDN distributions of Win7.

    Attrib does not see the snippingtool.exe either.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me



    Friday, February 17, 2012 1:24 AM

  • "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    The files shown are the same ones my toolbar Add File shows, not the files that are actually there thats why I say it must be an attribute of some sort. I am in an account with adminstrator privileges.

    Renee



    Friday, February 17, 2012 1:36 AM
  • I do see something very unusual in the permission of the directory (system32) and Windows of another Win7 system that I have installed this toolbar sucessfully.

    They both have an ACL of CREATOR OWNER that has NO privleges associated with the ACL.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me


    Friday, February 17, 2012 2:04 AM
  • It's related to privileges because when I run cmd with privleges, the tasks show up fine.

    So I have a direction now. I need to at least run the toolbar privileged at least long enough to add the snipping tool to the icon database. 


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me



    Friday, February 17, 2012 2:27 AM
  • Even with privileges, the ADD does not see c:\windows\system32\Snippingtool.exe and i dont know why, unless VB creates a process and runs it without privileges.

    The taskmonitor does not show a seperate process starting up. So I'm at a loss to see why when I run The taskbar as privileged, the ADD function does not 'see'   c:\windows\system32\Snippingtool.exe.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me






    Friday, February 17, 2012 3:07 AM
  • Hi Renee,

    This is just a stab in the dark, but are you running a 64-bit Win7 and could this problem be related to the "File System Redirector"?

    http://msdn.microsoft.com/en-us/library/aa384187%28v=VS.85%29.aspx

    Friday, February 17, 2012 3:42 AM
  • TinTin - YES I am running from 64 bit windows, but the tashbar is built 32 bits.

    But I do not know the answer to your question. The taskbar is built in 32 bits and the tasks that  I cant see are in system32 sugesting strongly that they are 32 bit tasks.

    Let me read up. The system that I did install this on is 64 bit Win7. let me read.....

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Friday, February 17, 2012 3:54 AM
  • TinTin - YES I am running from 64 bit windows, but the tashbar is built 32 bits.

    But I do not know the answer to your question. The taskbar is built in 32 bits and the tasks that  I cant see are in system32 sugesting strongly that they are 32 bit tasks.

    Let me read up. The system that I did install this on is 64 bit Win7. let me read.....

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Renee,

    My understanding of this is that on a 64-bit OS, the files in System32 are actually the 64-bit versions.  The 32-bit versions are stored in the SySWOW64 directory.  Counter-Intuitve to say the least.

    From the link I provided: "32-bit applications can access the native system directory by substituting %windir%\Sysnative for %windir%\System32".

    Good Luck navigating this rabbit hole.

    • Marked as answer by Renee Culver Friday, February 17, 2012 8:28 PM
    Friday, February 17, 2012 4:09 AM
  • I don't know....

    The toolbar is definitely built as a 32bit process on a 64bit system. According to Explorer, there is one copy of Snippingtool.exe and it's in c:\windows\system32 and it shouldn't make any difference but I surmise that it is 32bit being in that directory.

    I wondering what trick i used to use?

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Friday, February 17, 2012 4:22 AM
  • TinTinmn,

    Thank you first of all.

    I don't think the fix (sort of) will be as simple as you think. Adding to the toolbar is a component of the toolbar, and toolbar is complex to make the user interface simple.

    I haven't written the code or the Operating system which is unfortunate. All I do is call a component and it's that component which does not see what it's supposed to. It's one of those problems that you have when you have amateurs writing OSes. Let me run some utilities and determine some things.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Friday, February 17, 2012 4:58 AM
  • I fear that what you say is true, which among other things means I've designed backwards because I've assumed that the tasks in system32 were 32 bit tasks. WRONG Renee.

    But that aside from my orginal request butt i"ve learned somethings. Notice that Imageheader found as saw Snippingtool.exe OK and it uses the same input methods as taskbask but (I think) it's a 64 bit task and it saw snipping tool ok. But the toolbar is 32 bits for a reason. It referers to a microsoft library that so far is 32 bits....

    I will have to do more checking to see if a can find a 64 bit copy of that library which is tlbImp.exe which in the build is 32 bits. If if I can find a 64bit copy of that library i can rebuild the toolbar...and see the snippingtool and be finished with MS bugs for the time being.

    I will keep this thread informed because this is real and important.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me


    Friday, February 17, 2012 5:26 AM
  • Hmmm. This is a search and I have referred to the library no where in my code. Im still trying to determine the ramifications of all of this... If there has been a COM library constructed that is why I cannot go to 64 bits with this project. But there are even more insidious ramifications than this. The fact that I cannot see Snippingtool.exe to add it is a non-trivial bug and the bug is microsoft's. CrazyPenny, this isn't my bug.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me


    Friday, February 17, 2012 6:07 AM
  • Well now I'm hornswaggled because I found a 64 bit copy of toolbar. I do not know how I made it. However, the 65 bit version saw SnippingTool.exe just fine and I added it to the toolbar just fine. The 64 bit copy was made 7/10/2010. Wonder what I did to build this on 64 bits? Here's a picture of the directory listing and a copy of header information showing that at one time the toolbar could be taken to 64 bits.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    • Marked as answer by Renee Culver Friday, February 17, 2012 7:50 AM
    • Unmarked as answer by Renee Culver Friday, February 17, 2012 2:56 PM
    Friday, February 17, 2012 7:49 AM
  • The copy that I found was many years old. Its database was well designed and unchanged.

    The thing that currently has me locked into 32 bits for the toolbar is the interop.scripting.dll added when I added an About interface to Help.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Friday, February 17, 2012 1:51 PM
  • No, that's not the answer. The 32 bit sftware really does not see snipping tool.exe.

    IF it does see not it in 32 bits....it really does see it in 64 bits. :(

    Right now as implented, I cant go to 64 bits :( becuse of COM software in the software.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Friday, February 17, 2012 3:01 PM
  • The thing that currently has me locked into 32 bits for the toolbar is the interop.scripting.dll added when I added an About interface to Help.

    Renee,

    This statement puzzles me a bit.  By "an About interface"  do you mean the standard VS "About Box" template?  If so, there should be no reason for that to be adding interop.scripting.dll. 

    I believe that dll is added when you add a COM reference to "scrrun.dll" (Microsoft Scripting Runtime).  If it is the scripting runtime, I would think that you could replace whatever functionality it providing with standard components.

    • Marked as answer by Renee Culver Friday, February 17, 2012 8:33 PM
    Friday, February 17, 2012 3:22 PM
  • Does this help?
    http://msdn.microsoft.com/en-us/library/aa365743(VS.85).aspx

    In addition, from a 32 bit application you can see the path c:\windows\sysnative (don't look for it in Windows Explorer; you won't see it)


    Armin

    Friday, February 17, 2012 4:01 PM
  • Hi youall

    I think I have it fixed by putting an old 32-bit version in, afterall-it's just a toolbar and the old 32 bit version sees the snippingtool.exe just fine. Since the source has not changed, more and more, this points to a microsoft bug. When I build it from the sources that work now, it no longer works. Using a old toolbar works.

    TintinMN

    I said this is a complicated toolbar. Here is the main about box written in 2005. It was one of the first vb projects I did:

     

       Private Sub AboutBox1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

            Me.Controls.Add(lbRunningDirectory)

            Me.Controls.Add(lbDataDirectory)

            lbRunningDirectory.Location = New Point(0, 56)

            lbRunningDirectory.ForeColor = Color.Red

            lbRunningDirectory.AutoEllipsis = True

            lbRunningDirectory.AutoSize = True

            lbDataDirectory.Location = New Point(0, 87)

            lbDataDirectory.ForeColor = Color.Red

            lbDataDirectory.AutoEllipsis = True

            lbDataDirectory.AutoSize = True

            Dim Application As String = System.Windows.Forms.Application.ExecutablePath

            Dim fso As Scripting.FileSystemObject

            fso = CreateObject("Scripting.FileSystemObject")

            Dim fileobject As Scripting.File = fso.GetFile(System.Windows.Forms.Application.ExecutablePath)

            lbCompiled.Text = fileobject.DateLastModified

            Me.Text = FrmToolBar.Text

            Me.lbVersion.Text = System.Windows.Forms.Application.ProductVersion

            lbRunningDirectory.Text = System.Windows.Forms.Application.ExecutablePath

            Me.lbVersion.Text = String.Format("Version {0}", My.Application.Info.Version)

            lbDataDirectory.Text = FrmToolBar.Sio.AppDataPath

            fileobject = Nothing

            fso = Nothing

        End Sub

    The scripting object was only available in 32 bits. It appears that this tool bar, unchanged from 2005 and coupled with the toolbar databases of today - do the trick.

    There is a button for the snippingbar. I do not use a standard of any Kind. I actually write software.

    Here's a snipping of the about box:


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me




    • Edited by Renee Culver Friday, February 17, 2012 8:06 PM
    • Marked as answer by Renee Culver Friday, February 17, 2012 8:19 PM
    Friday, February 17, 2012 7:37 PM
  • " If it is the scripting runtime, I would think that you could replace whatever functionality it providing with standard components."

    This is indeed worth some thought but not right now. I have a new X3960 and I just had to get a new sabertooth board  for it. I'm busy reassembling the system which I was doing when I ran into this. The old system was corrupted and I didn't know it. At some point I deleted the good system and backed up the corrupted one.

    Please remind me in a month. I'll need it. :)

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me



    Friday, February 17, 2012 8:18 PM
  • " If it is the scripting runtime, I would think that you could replace whatever functionality it providing with standard components."

    By the way....WE do not use or write scripts. It's called source code.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Saturday, February 18, 2012 12:26 AM
  • Actually I don't knoe and I wish I did. The corrections are all written in C++ and I  have VB. I didn'y at first-glance, see a way to use it. BUT I am begiing C++ learning today. I have been oppsitional to it....but now I am beginn ing to wonder why. At DEC we were universally opposed to C.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Tuesday, February 21, 2012 7:04 PM
  • "If the access causes the system to display the UAC prompt, redirection does not occur. Instead, the 64-bit version of the requested file is launched. To prevent this problem, either specify the SysWOW64 directory to avoid redirection and ensure access to the 32-bit version of the file, or run the 32-bit application with administrator privileges so the UAC prompt is not displayed."

    Ummm one of the first things I do to Windows system when I get it, is to turn the UAC off. Despite the double negatives in reading the article as I run Windows, I think it says that firing the UAC temporarily disables redirection. There is one difficulty which is that it's possible that this is the problem but I'm not sure I would know how to fix it. It is difficult to compare however.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me


    Tuesday, February 21, 2012 7:21 PM
  • Hi Renee,

    I saw that you are working on this issue again.

    I took a look at your "About Box" code and it appears that you are using the Scripting Runtime only to retrieve the "DateLastModified" property for your application.  This is easily replaced with the System.IO.FileInfo class.

    i.e.:    lbCompiled.Text = New System.IO.FileInfo(Application).LastWriteTime.ToString

    Actually I don't knoe and I wish I did. The corrections are all written in C++ and I  have VB. I didn'y at first-glance, see a way to use it. BUT I am begiing C++ learning today. I have been oppsitional to it....but now I am beginn ing to wonder why. At DEC we were universally opposed to C.

    I'm assuming that this is in response to the article that Armin referenced.  Not that I want to discourage you from learning C++, but you could access that function using InterOp.  I put together this class to encapsulate the functions, but I have no way of testing it.

    Public Class WOWRedirect
       Public Shared RedirectPointer As IntPtr = IntPtr.Zero

       Public Shared Sub DisableRedirect()
          If RedirectPointer <> IntPtr.Zero Then
             Throw New Exception("Disable Redirect already called")
          Else
             Dim result As Boolean = Wow64DisableWow64FsRedirection(RedirectPointer)
          End If
       End Sub

       Public Shared Sub EnableRedirect()
          If RedirectPointer = IntPtr.Zero Then
             Throw New Exception("Redirect already Enabled")
          Else
             Dim result As Boolean = Wow64RevertWow64FsRedirection(RedirectPointer)
             If result Then 'clear pointer
                RedirectPointer = IntPtr.Zero
             End If
          End If
       End Sub

       <Runtime.InteropServices.DllImport("kernel32.dll", SetLastError:=True)> _
       Private Shared Function Wow64DisableWow64FsRedirection(ByRef ptr As IntPtr) As Boolean
       End Function

       <Runtime.InteropServices.DllImport("kernel32.dll", SetLastError:=True)> _
       Private Shared Function Wow64RevertWow64FsRedirection(ByVal ptr As IntPtr) As Boolean
       End Function
    End Class

    Tuesday, February 21, 2012 9:07 PM
  • Thank you Tinmn. Your reponse deserves careful attention when things settle to a dull roar.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Wednesday, February 22, 2012 12:35 PM
  • Tinman,

    Can you give me a description of what goes wrong with redirection?

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Wednesday, February 22, 2012 12:45 PM
  • Is this what you are talking about re redirection:

    When a Process writes text to its standard stream, that text is typically displayed on the console. By redirecting the StandardOutput stream, you can manipulate or suppress the output of a process. For example, you can filter the text, format it differently, or write the output to both the console and a designated log file.

    Note Note

    You must set UseShellExecute to false if you want to set RedirectStandardOutput to true. Otherwise, reading from the StandardOutput stream throws an exception.

    The redirected StandardOutput stream can be read synchronously or asynchronously. Methods such as Read, ReadLine, and ReadToEnd perform synchronous read operations on the output stream of the process. These synchronous read operations do not complete until the associated Process writes to its StandardOutput stream, or closes the stream.

    In contrast, BeginOutputReadLine starts asynchronous read operations on the StandardOutput stream. This method enables a designated event handler for the stream output and immediately returns to the caller, which can perform other work while the stream output is directed to the event handler.

    Note Note

    The application that is processing the asynchronous output should call the WaitForExit method to ensure that the output buffer has been flushed.

    Synchronous read operations introduce a dependency between the caller reading from the StandardOutput stream and the child process writing to that stream. These dependencies can cause deadlock conditions. When the caller reads from the redirected stream of a child process, it is dependent on the child. The caller waits for the read operation until the child writes to the stream or closes the stream. When the child process writes enough data to fill its redirected stream, it is dependent on the parent. The child process waits for the next write operation until the parent reads from the full stream or closes the stream. The deadlock condition results when the caller and child process wait for each other to complete an operation, and neither can continue. You can avoid deadlocks by evaluating dependencies between the caller and child process.

    For example, the following C# code shows how to read from a redirected stream and wait for the child process to exit.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Wednesday, February 22, 2012 12:52 PM
  • And why do some most files show up but some files do not in VS2010?

    Renee 


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Wednesday, February 22, 2012 1:06 PM
  • Is this what you are talking about re redirection:

    When a Process writes text to its standard stream, that text is typically displayed on the console. By redirecting the StandardOutput stream, you can manipulate or suppress the output of a process. For example, you can filter the text, format it differently, or write the output to both the console and a designated log file. ....

    Hi Renee,

    No, the redirection referred to in the your referenced documentation is a different animal altogether.  The redirection I was referring to is in relation to 32-bit applications running on a 64-bit WinOS and trying to access files in the System32 directory.  In crude terms, a virtual directory system is established for the 32-bit application to ensure that it loads 32-bit versions of system dlls, drivers, etc. that are stored in the SysWow64 directory and not the System32 directory.

    I'm no expert in this and only know what I have read about 64-bit programming.  I see no point in confusing the issue further with my limited knowledge, so I will refer you to the relevant documents.

    The redirection that I was referring to is described in Programming Guide for 64-bit Windows

    The relevant parts are:  Registry Redirector and File System Redirector.

    After re-reading the information, I suggest you pay heed to the notes on disabling the redirection for as little time as possible if you choose to go that route.

    And why do some most files show up but some files do not in VS2010?

    Just a guess, but I suspect that your application compiled as a 32-bit application is being redirected (oops, there's that nasty word again) to the SysWoW64 directory when you believe it to be looking at the System32 (physical) directory if that is the directory of interest.

    Look on the bright side, probably in about ten years we will have to contend with legacy 64-bit application issues on a 128-bit OS.  :^)


    • Edited by TnTinMN Thursday, February 23, 2012 1:45 AM typo
    Thursday, February 23, 2012 1:43 AM
  • Thank you so much! When the code is compiled on Vs2008, I have full visibility.

    The intermittent results are the same code on VS2010.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Thursday, February 23, 2012 7:11 AM
  • Btw, I know the definitions of Asych and Synch well.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Thursday, February 23, 2012 8:54 AM
  • "Just a guess, but I suspect that your application compiled as a 32-bit application is being redirected (oops, there's that nasty word again) to the SysWoW64 directory when you believe it to be looking at the System32 (physical) directory if that is the directory of interest."

    Digital would have NEVER done this. Too bad that ms doesn't know how to make a real 64 bit operating system.

    I doubt we will ever see a 128bit system and I know I wont.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Thursday, February 23, 2012 8:59 AM
  • One more comment.

    My code, when compiled in VS2008 works. These problems only occur with the same code is built in VS2010.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me


    • Edited by Renee Culver Thursday, February 23, 2012 9:22 AM
    Thursday, February 23, 2012 9:20 AM
  • One more comment.

    My code, when compiled in VS2008 works. These problems only occur with the same code is built in VS2010.

    The issue could then be related to the .Net 4 Framework.  Under VS2010, does the code work if you target the .Net 3.5 Framework?  If so, you are closer to identifying the culprit. 

    I just ran into this issue a few days ago.  The problem was related to the .Net 4 feature called "Embedded Interop Types" that when implemented (the default) caused my code to fail.

    Thursday, February 23, 2012 3:33 PM
  • Well, I've gone since 2/23/12 with no problems and now their back. I've rebiult the image and they are gone. The Snippingtool was not visible on a 64 bit system.

    I've addressed the problem by rebuliding the image....but....it's back.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me




    Sunday, March 25, 2012 3:12 AM
  • No....now the toolbar will not activate Outlook.exe.

    I have had to look a workaround which is to manually start the toolbar with admin privilges which I have never had to do.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me


    Sunday, March 25, 2012 3:26 AM