I want to be able to program LUA in Visual Studio 2013 Ultimate. I have BabeLua to try to do this. In the program there is a tab called settings. Within that tab there are 5 textboxes that I do not understand
LUA Scripts Folder -
Folder where the files are stored? (Documents/Visual Studio 2013/ Projects)?
Lua exe Path
Working Path
Command line
Setting Name
Can someone give me an explanation to all of these Fields?
This prompt seems to be slightly different than the one I am seeing with the latest update of babelua, but regardless:
Lua scripts folder: This should be the explicit path to some file folder where your script is located.
Lua exe path: explicitly provide the path to your exe (which you can download from here.
Note: be sure to download the windows 32 Bit version, even if your machine happens to be 64 bit. There appears to be some sort of bug
that prevents Babelua from running in debug mode with the 64 bit
version.
Working path: I just provide the same path to the folder containing the lua exe.
Command line: This is where you provide the name of the script(s) you want to run. If you wrote a file in your project called "script.lua" you would provide the name of that file, with the extension, in this area.
Lua project name: This is different than the "setting name" prompt you have, but its rather self-explanatory.
Example:
Lua scripts folder: C:\Users\kevin1michael\Documents\LuaScripts
Lua exe path: C:\Users\kevin1michael\Documents\Lua\32BitLua\lua5.1.exe
Working path: C:\Users\kevin1michael\Documents\Lua\32BitLua
Command line: script1.lua
Lua project name: Project1
Related
I recently installed vs15 - preview (Stripped down version of visual studio 2015).
I am able to compile C/C++ sources from inside the IDE, but I am not able to compile with the command line interface cl.exe. It can't find the c stdlib headers. I tried to use vcvars32.bat to set the proper reg values but seemingly it cant find the "Common Tools Folder".
"ERROR: Cannot determine the location of the VS Common Tools folder."
The script uses the env. variable "%VS150COMNTOOLS%".
If I try to run "cd %VS150COMNTOOLS%" from the cmd line, it can't find the path, so this seems to be the main problem.
How can manually set %VS150COMNTOOLS% to the right path? how can I set the cmd linker settings manually (Without telling the cl.exe every time I call it)?
Okay, I solved it by adding the path to the include directories and lib directories to the env. variables as "INCLUDE", "LIB". It works now, whyever the script was not able to set those values properly. I am not fluent in reading .bat let away writing in, I assume the directory structure, which is different for the vs15 preview when compared to the full version, had not been adapted yet.
I'm trying to get tcl/tk working in Windows 7 64bit. I've followed the readme on the main tcl's website and what I've done so far is run the make file found in the tcl8.6.1 .zip file you can get off of the tcl website. I was able to compile it with the terminal window in Visual Studio C++ 2010 professional. The make file creates a folder inside your downloaded and extracted tcl folder that you can then run and compile tcl scripts from that specific location but from nowhere else. I want to be able to compile and run tcl scripts from any directory since I'll be doing a bit of tcl/tk programming in the near future.
Stuff I've tried:
1. Copying the tclsh86t.dll file + tclsh86t.exe file to system32
2. Editing the TCL_LIBRARY environment variable but it doesn't exist :/
Any ideas?
I figured it out. In Windows:
Open a file explorer
Right click on "computer" select "properties"
Select "Advanced System Settings"
Select "Environment Variables" in the "Advanced" tab.
Edit the "Path" variable to have the location of "tclsh86t.exe" available when compiling the latest version of tcl.
When you re-open your command line, you should be able to use tclsh86t.exe from anywhere. In my case, tcl was complaining that it couldn't find a usable init.tcl file. So, I went and grabbed one from the tcl distribution and put it where it was looking and then it was fine. You can alternatively edit your TCL_Library environment variable to point to wherever it is on your PC.
Using Advanced Installer, I have created and run a simple installer that contains a single .exe.
This .exe started as an executable jar (w/ splashscreen) and was built into a Windows .exe using Launch4j.
Once the application is installed (in C:\Program Files (x86)...), I can't execute it from the installation directory. However, if I copy the .exe to anywhere else, Desktop, or any other directories created by other installers, the .exe will start perfectly.
This appears to be a folder or application permissions issue. Comparing the permissions between this folder and the one created by Advanced Installer, the permissions and settings are identical.
The ONLY difference I see, between the installed .exe and the same .exe copied to another folder, is that the "Edit Permissions" button has an admin shield on it (one originally installed by AI).
Is there a setting in Advanced Installer that will allow my .exe to run once installed, or is this just trickery employed by AI to get you to pay for a more robust version? I am unable to make any changes in the OS that enable this file to run in the directory created by AI.
If the executable fails to run from Program Files but does works from another folder it most probably happens that your EXE needs write access to that folder. If you launch it with the option "Run as administrator" it should work. This is not caused by a limitation from Advanced Installer.
Starting with Vista onward you can embed a manifest file into an executable file, that specifies for the OS the execution level, so you can set the level to "RequireAdministrator", thus your will EXE will always behave as you launch it with the option "Run as administrator" when launched from a shortcut or double-clicked.
The cause of this error was that the target directory included an exclamation mark. "!".
I had switched to using InnoInstaller and it was working in an initial version, until I later switched the target dir to include the exclamation mark, and it was broken in the same way. (Removing it fixed.)
Have no idea why this was causing the problem, just an fyi.
I am trying to set up the ODE source code to work in visual studio. I have followed to instructions given in this link, which say to cd to the build directory and run the commnad premake4 vs2008.
that runs fine, and indeed, all the vs2008 files are created. But when I try to compile the project, I get an error saying that ode.dll cannot be found - should it be downloaded\installed separately or am I doing something wrong?
you should take a look a this link below
http://sourceforge.net/apps/mediawiki/arsproject/index.php?title=Main_Page#Visual_Studio
go to the section (middle of the page) Open Dynamic Engine (ODE)
Installation Steps for Windows.
I followed these steps and the installation works fine. In the ODE lib folder, do you have 2 folders
with name such as DebugDoubleDll or ReleaseDoubleDll? if you have compiled in double precision.
If yes, you should have a library named ode_doubled.lib in the ODE lib folder.
Did you try to run the demo executable to test your installation?
Last thing, did you include in your PATH environment variable the lib folder (where the libraries are located), if no, it's probably the reason why you have this error message.
On Windows Server 2008 64-bit, I need an .msi installer file to write some files to \windows\system32\inetsrv folder. (The files are some XML Schema validation files, that C# XmlReaderSettings.Schema.Add() expects to be in that folder).
When the installer runs, the files end up in \windows\SysWOW64\inetsrv folder, not where they need to be.
I attempted to have the installer then write to \windows\Sysnative folder, and the installer created a folder with that exact name, which I didn't expect to be possible. See this page for a good discussion on suppressing SysWOW64 redirection.
How should I get the .msi to write my files to the \windows\system32\inetsrv folder on Windows 2008 64-bit?
Here are the system folder properties you can use. I know it is counter-intuitive, but have you tried System64Folder? Read the remarks.
If that doesn't work, try just tacking System32 on to the end of WindowsFolder.
Edit-1: Try setting the Win64 attribute on your Component element and see if the redirection behavior changes.
I tried to use Sysnative in wxs file but I got the same result: create a Sysnative folder under Windows instead of using System32.
So I used Sysnative in a vbscript CA: found the Windows folder (&H24&) and append \Sysnative. This works, but a second CA is needed to delete the files during uninstall.
I solved my problem by writing the files to \windows, rather than \windows\system32.
It turns out that the C# XmlReaderSettings.Schema.Add() will work with a fully qualified path under the \windows directory. It just defaults to the system32 folder if the path supplied is not fully qualified.
This isn't really an answer to the question, but it is a work-around for my immediate needs.