I am running Visual Basic 6.0
never had a problem with it before but today when I tried to add the rich text edit component to a new project, it was not in the list of components. I have googled the problem to no avail. i even went to the trouble of i uninstalling and reinstalling visual studio. still didn't help.
does anyone know how to fix this?
The file must be installed and registered on your computer before you can use it.
It is called Microsoft Rich Textbox Control 6.0. Look for the file richtx32.ocx. You may need to use the browse button on the components dialog if vb cannot find the file.
If the file is missing, it may be included in VB6 service packs at http://msdn.microsoft.com/en-us/vstudio/aa718364
Related
I am currently working on a new unity project and to be honest i am new at this.
I need to use the InputSystem package but Visual studio does not recognize it.
This is the version of my VS. Microsoft Visual Studio Community 2019 Version 16.9.3 and the version of Unity is 2020.2.1
As you can see by the picture, my VS already knows that I am working in a Unity project.
So the first thing that I tried doing is to regenerate project files but it didnt work. I also selected my VS as my default external script editor.
This is my external tools.
I re-installed VS using unity hub but nothing happend.
Do you have any suggestions? I followed some tutorials I saw over the internet but I am still getting no positive results and to be honest, I am getting out of ideas.
Just tested out the package installation. I installed the package in a fresh, empty Unity project. Here are the steps that I went through which worked in my case:
Locate the Input System package in the Package Manager
Click install
A warning prompt will appear, click yes
Unity Editor should now get re-launched on it's own, wait for that to happen
If Visual Studio is open, close it
Open Visual studio - right click on the Assets folder and select Open C# project
UnityEngine.InputSystem namespace should now be available, if not, re-open Visual Studio one more time
Let me know if it works for you.
For me works when I install .NET and .NET Core and reboot the computer. (made this on Windows)
https://dotnet.microsoft.com/en-us/download
https://dotnet.microsoft.com/en-us/download/dotnet/3.1
I am by no means a visual studio expert. However I have done some searching on this topic and cannot find anything to help me.
I'm working on a VS 2010 web application. We are using TFS 2012 for source control. I wouldn't be suprised if this is causing my issue so I make a special mention of it.
The issue I'm having is every morning after I open the project I have to go into Tools / Extension Manager and search online and add JScript Editor Extensions. When I open the project the next day it's gone and I have to add it again. (I think sometimes it does this right in the middle of coding - my Javascript window changes size and loses formatting)
An extension that stays every day regardless is NuGet package manager, so it's not removing every extension.
I suspect that when I get latest from TFS it's overwriting the solution or project which contains the reference to the extension but I haven't been able to verify this.
Can anyone tell me why extensions would be removed? Are these a local user setting or are they contained in the project file?
Taking a step back, my real problem is complete lack of integration between C# and Javascript in the web programming world. I need all the help I can get on the Javascript side.
There were a number of issues with buggy extension addins. To clarify are you using visual studio 2010 with tfs 2012 plugin?
The recommended process for identifying the buggy extension is to disable the extensions one at a time until the buggy one is isolated.
the source control shell for tfs2012 can be installed as a separate shell if needed.
I suspect the script editor extensions however.
I am using Sandcastle Help file builder (1.9.4.0), Sandcastle (2.7.0.0) and .NET Framework 4.0 assemblies to generate the Class reference for Visual Studio.
I have used Framework version is .NET 4.0.30319 and Help File Format is MSHelpViewer and Presentation Style is vs2005 in Sandcastle Help file builder. It is working fine in VS 2010 (Help viewer 1.1). It shows Script error in VS 2012 (Help Viewer 2.0).
Shall I need to change any settings to solve this issue?
I randomly get this error. There's a lot of stuff online that requires you to mess with the registry and such. A much easier solution I found somewhere is to go to select Manage Content icon, and then make some change to the Help contents that you have selected, for example Add in some help topic that is currently not in, or Remove some topic. Then click Update, and its usually fine after that!
I have the error I wrote in the title when I'm trying to launch the application. I searched with google and I didn't find any page with 'LocalDebuggerWorkingDirectory' keyword. The solution contains a mix of c# and c++ projects and it worked fine until today... I use Windows 7 and Visual Studio 2010. Do you know where I can find this property to change it or how can I add it?
I can repro that, your startup project must be a C++ project. Right-click it, Properties, Debugging, Working Directory setting. Yours is empty. The default is $(ProjectDir)
I have a legacy VB6 app that I still need to support. I also have a new PC and I would like to copy my custom toolbar that I created on my old PC. Does anybody know where Visual Studio 6 custom toolbars are persisted to?
Thanks
I think you are talking about an addin. Addins written in VB6 for VB6 use a reference to Microsoft Visual Basic 6.0 Extensibility. You compile the application as an ActiveX EXE and as such it can be placed anywhere on the hard drive. You can look at vbaddin.ini for the *addin.*Connect setting where addin will be the addin name. Unfortunately this is not the file name or path, but it should be close enough to help you search the the application.
I don't know where that is stored, but you could try running Process Monitor from SysInternals, and see what VB6 writes to files and the registry when you change your custom toolbar. To be honest though, it'll probably be quicker to set the toolbar up by hand.