Does anyone know which windows-APIs are used by the explorer.exe to find the files of a directory?
In Windows XP it used FindFirstFileW() and FindNextFileW(), but on windows vista and 7 the explorer does not use them anymore...
The newer Windows versions automatically sort the Files in a Folder when opening them.
It is possible to restore the old behaviour.
A description how to do that is here
Related
I'm encountering the following
System.Runtime.Remoting.RemotingException error when I create a blank
Windows 10 Universal Application...
Following are event viewer screens...
I have checked online for other solutions and have already done the
following...
Uninstall/Repair Visual Studio 2015 Update 1
Reset my Windows 10 PC 1511 update
Cleared the Designer/ShadowCache folder
Target environment has been set to x86/x64
Target framework set to 10240
Developer mode enabled
Updated graphic drivers
Have cleaned and rebuilt solution
Updated to VS15 Update 2
Please let me know if you have been able to find a solution to the above
UWP applications fail to launch from Visual Studio if project location and Windows Store apps installation path are on a non-default drive. Also, the XAML Designer will crash if you install Visual Studio and Windows Store apps to a non-default drive
Windows 10 allows users to change the default storage location of Windows Store applications. If you select a non-default drive for your apps, and if you install Visual Studio 2015 onto this drive, the XAML designer will not start and Windows Store app projects built on this drive cannot be run from Visual Studio.
Note: the workaround below will make any Store apps installed to the secondary drive inaccessible until next restart.
The file system driver can be temporarily disabled by running the following command from an admin command prompt:
fltmc detach filecrypt :
This will enable both running apps from this drive as well as usage of the XAML designer until the machine is restarted.
For a longer term fix, move your app or Visual Studio install to your system drive, or a secondary drive that has never been the storage location for Windows Store apps.
I had the same problem. I started visual studio as an administrator and the designer came back.
You might want to try to clear the XAML Designer Shadow Cache. I've fixed al sorts of ailments with this process.
Its been a few months but I have finally been able to get the XAML Designer to work.
As #peterfaraday mentioned, the XAML Designer only works if you install Visual Studio on the System Drive (C: in my case) instead of using any other drive.
After uninstalling Visual Studio keep the following things in mind...
If your system partition is small, look to increase the space as the installation can take a lot of space based on the components selected.
If you had already installed VS on any other drive, while reinstalling you will not be able to change the default installation directory.
This is because your initial path of installation was saved as in the registry. I tried solving this issue by following these steps. In my case I had found multiple keys in the registry and hence "Reset this PC" (Windows 10) by allowing only for my personal files to remain. This cleared out all the registry keys and I was able to install VS back on the C: drive, resulting in the XAML Designer finally working (Please note that resetting your pc will remove any applications installed on your machine)
I got the same problem months ago. I Cleared the cache and Rebuild the solution. I got success.
I have windows embedded 8.1 Industry Pro (64bit) and office 2010. I did everything that I was supposed to do ;
Just extract the .ocx file from the .cab file and Copy to the system folder c:\windows\sysWOW64 for 64 bit systems
Use regsvr32 through the command prompt admin to register the file "regsvr32 c:\windows\sysWOW64\mscomct2.ocx"
But when I go to additional controls, there's no "microsoft date and time picker."
What can I do ?
Thanks
After 2 hardworking days finally I found my problem. My problem was office64 bit edition not supports every activex like mscomct2.ocx when I installed office32 bit problem solved.
I created an .exe using AutoHotKey. I created it in Windows XP. I've pushed it to some other users who are using later versions of Windows (Vista and/or 8). The .exe is not working in their systems. I don't see any activation of windows or any keystroke functions.
The .exe is opening windows and inputting keystrokes in XP.
Thank you
You have to run AutoHotKey under the Administrator account. See explanation in this article, AutoHotkey cannot interact with Windows 8 Windows…or can it!
I'm trying to figure out why the simplest firebreath plugin wont install on a German Windows XP SP3. I'm running Windows XP as a virtual machine.
The event viewer in Windows XP tells me something about the Windows Installer aborting but not why. I'm logged in as the administrator.
The installer works on Windows 7.
For development I use Windows 7, Visual Studio 2010 and some one months old firebreath trunk.
Is this is known problem? What are the typical steps I could use to track down the issue?
Regards,
Christian
If you get an error saying module can't be found it means that you are missing a .dll file needed to make the plugin work. The most common if it works on most computers (or many) but not that one is that your .dll was compiled with a dynamic runtime, in which case you'll have to install the common runtime for whatever version of visual studio you compiled it with.
For example, the runtime distributable for vs2008 is at http://www.microsoft.com/en-us/download/details.aspx?id=29
Dependency Walker might help you to find out which dll is missing.
I'm using this code in XP 32-bit OS to get the %windir%\windows\system32 folder path.
sysFolderPath = Environment.GetFolderPath(Environment.SpecialFolder.System)
What I want to know is that will this same code return the %windir%\windows\syswow64 folder when used in Windows 7 (64/32-bit)?
It will return c:\windows\system32, even in a 32-bit program that runs on the 64-bit version of Windows. Do not fix this, it doesn't need fixing. Because when you use that path, Windows will automatically remap it to c:\windows\syswow64. The file system redirector takes care of it.
I tried on my Windows7 box with .NET 4.0
This code:
Console.WriteLine(Environment.GetFolderPath(Environment.SpecialFolder.System));
Console.WriteLine(Environment.GetFolderPath(Environment.SpecialFolder.SystemX86));
Prints the following from both 32- and 64-bit process:
C:\Windows\system32
C:\Windows\SysWOW64
Nope. On my Windows 7 64-bit box, targeting x64:
C:\Windows\system32