We are using jBASE 5.6 multivalue database. Is there a way to disable the fact that AccuTerm's WED Editor has the ability to compile programs in the underlying MultiValue database? We are running into an issue where the user is accidentally compiling records instead of programs, which creates corrupt records in the datafiles.
I believe there is also a shortcut key (Function Key) that is in use. Help!
As of AccuTerm Release 7.3a there is no explicit option to disable the compile shortcut in the AccuTerm wED (Windows Editor). There are two techniques you can apply, however, that will work:
Change the Compile command to a single space
Open the wED
Click on the Tools menu at the top
Click on Settings
Click on the Tools tab
In the Compile section, change the text in the Command input from BASIC to a single space. Note that some flavors of PICK use BASIC as the compilation command whereas others use COMPILE. Since you are running jBASE, BASIC applies in this instance but for others such as D3 the command to replace is COMPILE.
It is possible to write a wrapper program to handle compilation for you, which when cataloged could be called from this same Command input. That program could be written to decide whether or not the target record exists in a code file or a data file and then compile or skip, respectively. Due to the fact that PICK systems do not have a file type specification, this logic would be somewhat unique to your environment depending on your practices. Common practice is to denote code files as BP files, i.e. FileNameBP or FileName.BP but again it would depend on your implementation.
For the record, a request to have a more formal option for disabling the Compile command has been submitted to the AccuTerm development team for consideration in the next major release.
Related
I've ran into a problem during the C/C++ build using Eclipse/CDT for a project containing many source files - during the linking phase a very long command line is created that is then passed to CreateProcess Windows API function. This command is in format of: {compiler} {flags} path/to/file1.o path/to/file2.o path/to/file3.o [...] and essentially contains all object files created during compilation and in my case is over 34K characters long.
Now historically this has already been looked at, but in my feeling the problem was only raised to a higher character limit. In particular, when looking here it is mentioned there was a problem with 8192 character limit, which seems to be the case when the command was directly passed to command line. The change which attempted to fix it was to use CreateProcess WINAPI function instead, which has a higher limitation of 32767 characters (limits depend on version of Windows used). In case of the project I'm working with, neither limit is high enough, as I've already reached over 34K characters for that particular command.
I've mentioned GNU ARM Elipse as this is what I'm working with, however this is a general issue with the CDT itself and it seems to also be a problem in other IDEs - for example I've read the same kind of reports from Netbeans users. Because I work with embedded systems and there are tools already integrated with Eclipse, moving to another IDE isn't an option.
As for the actual solution - the ideal situation to me would be to have the list of object files passed through a temporary file, as the character limitation is completely bypassed this way. So far I'm using CTD's makefile generator, as it is integrated with the IDE itself (flags, build exclusions etc.), however it isn't configurable in any way or at least none that I'm aware of that would solve my issue.
What are my options here? If it's necessary I might look into the makefile generator itself and modify it to output to file, however I'd rather avoid doing so if it's not the last possible option.
I have a dtsx file that deals with more than 200 table export and script that log information before and after completing export of each table. I am trying to change the logging to include more details, It is a time consuming process to open one by one log script object, click edit and make my changes. I opened the dtsx file in notepad++ with regex, I updated the script text by adding more log information. But my changes are not in effect when I run SSIS.
When I open the modified dtsx file in visual studio 2013, double click log script object, click edit then add a space save on all the log objects then my changes are in effect.
I compared those two files (one modified from notepad++ other from visual studio), other than some GUID difference and my new space character there is no change. Why my changes are not in effect when I make them in notepad++? Am I missing something?
Excellent! The root issue is that much like if you make a change to a C# class file, those changes wouldn't be reflected in the application until you compile. That's what's happening here, you've changed the source script for the SSIS package but you need to compile that script into byte code so it can actually be run.
The 2005 release of SSIS allowed us to specify whether the code should be compiled at run time versus design time but that didn't work out well at all so at some point in the lifecycle of 2005, that ability was nixed and the code had to set at design time.
I think I've seen code to compile a script task/component but whether that was on SO or elsewhere is a mystery at this point. I believe Matt Mason indicated there were changes in how things compiled between 2005/2008 and 2012+ but I can't find the post. There is this post which might give you a shove in the right direction for which classes you'll need to use to get the packages to compile.
Currently, I have an MFC C++ visual studio project that is built to a DLL. Let's call it the FinalDLL.
I need this FinalDLL to be configurable. So, I want a GUI such that the users can generate the FinalDLL based on the information the enter via GUI. Please consider that I don't want to make the sources available at any points.
I do not have a clear idea how to integrate these steps. The solution I came up with was to have something like a button in my GUI, so that when it is clicked, the FinalDLL gets generated based on the information entered via GUI. Is it possible to do something like that? Probably I need another DLL library, as the information entered via GUI can be calls to functions that are used inside the FinalDLL source.
The solution to this would be very complex and complicated, mainly due to the fact that you don't want to disclose the source code of the DLL.
Basically you need to compile those source files every time you want to generate the DLL, and without the user having access to them.
Firstly, this is also required for the users that you want your DLL-generator app distributed to.
Secondly, you'll need to store those files somewhere in the app, and in an encrypted form, so that hackers won't just look at you app binaries and extract the source code for the DLL.
As a prerequisite on the user side, he will need to have a compatible Visual Studio installation, which will be used to compile on the fly the source code files.
What the DLL-generator application will need to do is to compile on the fly those source code files along with the customised ones via the form that the application will present.
So what you will need to do (the list might not be exhaustive due to the complex requirements):
Gather all compiler/linker commands that Visual Studio executes when building your project
Store all source code files into your application, in an encrypted form. Now if you want to allow your application to decode the files then you need to either store the encryption key within the application, and obfuscate it so its not that easy to find, or have the app communicate with your server and ask for the encryption key via https (this is a more secure approach, however neither this is 100% bullet-proof, insistent/trained hackers can still peek into the memory used by your app)
After the user fills all DLL generating details, the app will need to decrypt the source code files, updated the ones affected by the customised parameters, and start the build process by using the commands gathered at step #1. The compiler/linker should allow reading from stdin, so you'll use pipes to write the source code contents to the compiler/linker stdin, and to obtain the compiled/linked objects from stdout.
As I said, the solution is not pretty, and the main problem will be having the users install a Visual Studio that comes with a compiler compatible with the one from your machine, otherwise the commands you gathered at step #1 will not work.
With Makefiles I'm used to being able to write things like:
includedir=$(shell pg_config --includedir)/server
to run an external program, pg_config, with argument(s) --includedir, and include the result in a variable or as part of a variable. So if pg_config --includedir output /usr/include to stdout, the value of includedir would become:
includedir=/usr/include/server
Is there any way to do the equivalent with a Visual Studio project? Run a command, get the result, and substitute it into a property?
I find myself having to edit properties pages all over the place - changing the include directories and library directories for both the x86 and x64 configurations of a project whenever I want to build an extension against a different PostgreSQL version. It is intensely frustrating.
I want to be able to put something like this into Configuration Properties -> C/C++ -> General -> Additional Include Directories:
%(shell pg_config --includedir)
or even better:
%(shell %(PG_CONFIG) --includedir)
where %(PG_CONFIG)'s location is defined in a single place for each platform in the project.
So I'm looking for at least user-defined macros, and preferably the ability to invoke a command line tool and replace the macro with the resulting standard output.
(Preferably in a way that doesn't involve delving into semi-documented UI elements that move and get renamed in every VS version, and that appear and disappear from the various Express editions).
This has been possible in Makefiles for 20 years, there must be a way to do it in VS, right? Or do "Real Windows Developers" generate their VS projects with scripts and build them using MSBuild?
I've looked at some similar questions without finding much of use, e.g.:
Visual Studio - Where to define custom path macros?
In particular, I'm aware of property sheets (View -> Other Windows -> Property Manager), but they don't seem to provide a way to set a value in just one place, they're still per-configuration and per-architecture, so if you have four configurations and two architectures it gets awkward. Unlike with the normal project property editor you can't even apply a change across a group of architectures/configurations, either.
I could use a VS extension, but they require installation into the user's VS, can be version-specific, and seem like a very big hammer for a small problem.
I find myself having to edit properties pages all over the place
That bugged me to no end as well. Property sheets to the rescue! When setting up a major solution in VS10, for example, I had every project pull in a settings.props that contained the common settings, made in only one place. Then go through all the generated or imported projects and kill any explicit value (even if blank) for everything possible. That way things will inherit from property sheets. Select "all configurations" and on each properly use the drop-down to "inherit from...".
I have property sheets for each special library too, just defining the proper #define, include paths, lib paths, etc. Projects that use that particular external lib simply use that property sheet. Users are told, in the worst case, to “edit the XML to change the path to where you have Boost”.
As for setting such a properly to a dynamic determined value, you can do that too. There are property functions you can use.
It sounds like you're going down the same path as I did.
More notes: “prop sheets are per configuration/platform”: If you include a prop sheet at the top-level node for the project itself (not the Debug|Win32, etc. child nodes) it will include it into all current configurations at once. If you edit the properly page, you can choose Multiple or All configurations on the Property dialog box, just as with the usual project use of the Property dialog.
“Custom user macros are well hidden” A property page shows up for that when in a property sheet you created, but not when opening property dialog on a proj file as in the normal File View. The macro will be set in one place (the prop page) and usable as a $(name) in all projects that include it, and even in other property pages that come later in the evaluation sequence.
Let me know how it goes. You should be able to do everything you asked.
—John
In addition to #jdlugosz's answer:
It looks like the traditional way to do this with Visual Studio, before the advent of property functions, was to write a new MSBuild Task. The task can potentially do things like modify a property sheet.
MSBuild supports "inline tasks" where the task code is in the MSBuild project file, rather than a separate assembly, so it might not be neccessary to create a new subproject just for the task.
There are a bunch of built-in tasks, like Exec and CreateProperty that may be useful.
The docs say that:
[The Exec task] is useful when a specific MSBuild task for the job that you want to perform is not available. However, the Exec task, unlike a more specific task, cannot gather output from the tool or command that it runs.
... but that seems to be outdated/wrong so you don't need horrible workarounds.
So, prior to .NET 4.5 I'd probably have to write a custom task for this simple job, because there's no way to feed the command stdout/stderr into the CreateProperty task or have Exec create a property directly. But in 4.5 it looks like I can do it directly. At least in VS Express support for tasks etc is very limited so you'll probably land up editing the XML.
I want to know what is the standard way of doing it.
currently I'm thinking in add a series of defines in a header file and inlcudie that file in the main resource file win win32 to update the version resource in win32 and in *nix make some global functions to return this information.
and in windows make the msi install file also reflect the same version.
That sounds like a reasonable way to do it. I don't think there IS a standard way of doing this; there aren't any real standards for version reporting that are cross-platform.
Since we wanted to avoid the overhead of changing a "version.cpp" or equivalent every time we hit build -- and thereby taking the time to do at least one compile and link -- we modify the binary after the build.
If you're outputting to e.g. ELF or PE format executables, you can use some basic knowledge of ELF or PE and a linker map to figure out what to replace, otherwise you can scan through the binary looking for a set pattern (we use something like static const char VERSION[] = "[VERSIONBLOCK xxxxxxxxxxxxx]";) and replace a portion (e.g. the xxxx part above) with relevant info:
build date and time
build machine
username
output of e.g. svnversion
Note that this won't work very well if your binaries are signed or compressed before this step, but usually you can engineer your build process so the signing/compressing happens after this step.
I'm sure a variant of this could be extended to hit the Win32 PE version metadata as well as any embedded version string.