Does anyone have experience developing with ESQL/C for INFORMIX-SQL, as in calling C funcs within "Perform" screen generator and "ACE" report writer?
I have ISQL without ESQL/C. I experimented compiling a perform screen, where in the instructions section I put "ON BEGINNING CALL userfunc() END" and although I don't have
ESQL/C, the Perform screen successfully compiled without errors!.. Apparently, the compiler didn't reject the C call even though there's no ESQL/C or C program linked.
Yes, I have some experience with them - dim and distant, now.
The form compiler (sformbld) has to accept any function call that you make - it cannot tell whether it will be valid or not at run time. It does not know which functions are available to the (custom) Perform runner that will be needed to run the form.
Similarly, the report compiler (saceprep) has to accept any function call that you make because it cannot tell whether it will valid or not at run time.
To run a form that contains a function call other than the built-in functions, you must create a custom runner (rather than using the standard sperform). The script to do that on Unix is 'cperf'; it will take the function definitions that you provide and build a custom runner that can call those functions. You can then run a report which uses those functions using the custom runner. If your custom code does not do any ESQL/C calls, you don't even need ESQL/C on the machine; the ISQL product is sufficient.
The parallel circumstances apply to reports; you cannot use the standard sacego but must create an appropriate custom runner with 'cace'.
Now, in the dim distant dark ages (say before 1990), you did not get the custom ACE and Perform stuff with ISQL - you had to buy ISQL and ESQL/C. But since ISQL version 4.00 was released (AFAICR, in 1988 or 1989), the custom runners and libraries were provided with ISQL and you no longer need to buy ESQL/C unless you want to build ESQL/C functions into your custom functions.
Note that you do not create a custom compiler; therefore, the compiler cannot tell what functions are available.
Related
I am pretty new to Informix and I have a program that I am adding some functionality to.
It seems that the program has some existing issues with it though.
When I run make -f makefile.mk I get success and the .4ge gets generated and I am able to run it.
However I am trying to get the program to run within informix 4gl interactive debugger but I get the error: Invalid module name [main] specified.
Any assistance would be greatly appreciated. Unfortunately I am unable to share code as the program contains confidential information
The Informix-4GL Interactive Debugger (ID) is for debugging programs compiled with the Informix-4GL Rapid Development System (RDS). The object files created by RDS (fglpc) have the extension .4go (I4GL p-code object file) and the executables are conventionally given the extension .4gi (I4GL p-code interpretable file — run using fglgo or ID's fgldb).
By contrast, the plain Informix-4GL (c-code) system uses an I4GL compiler to generate first ESQL/C code and then C code, and a C compiler to create regular object files (.o) and to create its executables, which are conventionally given the extension .4ge (I4GL c-code executable).
The ID cannot debug c-code executables. It can only debug p-code interpretable files.
On the face of it, therefore, your problem is that you are using the wrong tool for the job. Either you need to compile with RDS and create an interpretable, or you need to use a C code debugger such as GDB. However, be warned that debugging I4GL code with GDB is mainly an exercise in frustration as the bulk of the code is a series of function calls to library functions — or is an incredibly tortuous sequence of goto statements if you're debugging inside an I4GL report function. It is machine-generated C code; it is not intended to be comprehensible to humans.
I'm writing a test script in python that will manipulate memory in the system.
I know the m command (modify memory) exists; however, it seems extremely clunky. Our test suite does not handle input prompts very gracefully either. I believe there must be something better out there.
In your experience, what other ways are there to modify memory in VxWorks?
Target shell commands in VxWorks are no more that C functions - the shell includes a symbol table generated at build time that includes all functions with external linkage. As such the "m" command is in fact a simple a C function (see here). You could equally call memset() or memcpy() or write your own function.
To execute function calls on the target from a host, without using the target or host shell, you might consider using RPC using RPyC on the host perhaps.
We currently use Delphi 2009 and GIT to develop an application. We have set up a prebuild script to generate a version number and build ID using information from git and compile this as a resource that is included in the project. The problem is that this script doesn't run on a regular compile. This means that the other developers can end up with a discrepancy between the actual version number and the number in the resource (especially when switching branches in git).
Since we use our software to make some critical calculations, we would like to use this build id to reproduce calculations and track down problems.
Other than trying to force my developers to frequently press shift-F9, how can I ensure that the the prebuild script gets run when necessary (ideally at each compile)?
Jason
UPDATE: It's true that the pre-build script gets run at each compile. The problem was that I expected to get a different result pressing F9 after making a tag in git, even though no code had changed.
We solved a similar issue by writing a custom IDE plugin which uses the IOTAIDENotifier50 interface. Specifically using the BeforeCompile method, to test some required project settings and also generate dynamic version information (VERSIONINFO resource). It gets called for every type of build (compile and build). We also generate a unique exe serial number and log everything, which helps us track down issues and is similar to your script. For completeness we have only done this in Delphi 2007 and Delphi XE.
Pre build actions do run before every compile.
You state in a comment that the actions sometimes don't run when you press F9. That makes sense because F9, or Run, only invokes a compile if source is deemed to have changed.
A BeforeCompile notifier plug in will behave in exactly the same way. Your solution is to make sure that you compile before running using Ctrl+F9.
I need to make an app that will let users select some options, click a button, and a separate compiled app is created. Is this possible? I am using delphi 7 and 2010.
Thanks for the replies. Here is a little more info.
It would have to be a graphical app and create a graphical app.
What I want is the user to fire up 'App A' (I originally made), be able to select some options (I apologize for the secrecy. I think this is a million dollar idea that probably 3 people may find useful :) then use the program to create 'App B.' 'App B' can then be distributed to end users and 'App B' is a single executable that includes a compiled app plus the configuration data. I don't care how, but I need 'App B' to be a single executable.
I wouldn't even need to use Delphi for the final compiled app. If there is some sort of "pseudo-compiler" that I can call from Delphi that would marry a precompiled exe and a separate config file into a single executable. That would work just fine as well.
Thank you for the replies and help.
Thank you.
I also faced a similar situation once. I had to produce an exe using my exe. I didn't want to go the compiling a source code because of complexity and license problems.
Lets call the parent app P and child app C. Also lets assume that whatever option C needs can be summed up in a config file (XML/INI etc). What I ended-up doing was:
Create P and C. Inserted C in resource data of P.
When user clicked the button after selecting options, P would extract C from its resource data.
Created an XML file containing the options selected by user and inserted it in C's resource data.
So whenever C will run, it will use the options given in the XML file stuffed in it. It looks like complicated and hacky but is reliable and simple. Do a google on "delphi embedding resource in exe" and you will find plenty of articles to do above.
It is possible. You will need a Delphi 7 (or compatible) compiler (command line at least) on the target machine. You will also need all the source code for the compiled application and that includes all the third party libraries if you use any.
When you have it all set just call the command line compiler (DCC32.EXE) with the proper parameters and paths.
You can use two approaches for this:
Call ShellExecute
Call CreateProcess
You will have more control over the execution with CreateProcess. Also you will have to watch out for legal issues and licences if you plan to use the compiler this way.
Given that the Delphi compiler can't be redistributed, one solution if the user has not a copy of Delphi may be to use a script engine (i.e. RemObjects PascalScript, but there are others), generate code for it, and embed that code (i.e. within a resource) in an executable that will execute it when launched.
Create a separate stub executable that implements all the logic you need, and that reads its configuration from its own local resources (look at the TResourceStream class to help you load a resource at runtime).
Include that stub executable as an RCDATA resource in your main app's resources when it is compiled.
At runtime, the main app can extract the stub executable from its resources when needed, save it to disk, and insert the necessary configuration data into the stub's resources using the Win32 API UpdateResource() function.
Without knowing more about why you think you need to do this, I assume you don't actually need to do this. Given the stated requirements, I'd simply have one app, written in Delphi, that looks for the existence of configuration data (.ini file, registry, etc..) In the absence of this, it presents a screen that "will let users select some options, click a button". Then the options are stored in a .ini file, and the rest of the program proceeds, making use of those options.
Alternately, I'd use some pascal scripting, such as provided by TMS.
If you are looking for a way to crank out custom-branded versions of an app, maybe use Inno Setup with a ResHacker step. i.e. gather requirements in Inno, spit out your .exe into a temp directory, use ResHacker to modify the .exe, copy it into the program folder.
(This might be better in the TestComplete forums, but I thought I'd give it a shot here anyway)
We are looking in to automated testing of our Delphi 2010 application with TestComplete. The main control that our application uses is our own custom control that derives directly from TCustomControl.
(For reference the control is like a digraming tool that display boxes with text in them. These boxes can be selected. the control is completely custom drawn, including the selection).
We are looking in to making this more TestComplete friendly so we can read data out of it (e.g. what data is loaded in to the control, what data is selected)
I should also mention that our application uses an MVC architecture and makes heavy use of interfaces. TestCompletes debug agent can't seem to return any type information about interfaces and thus we can't get any data from them. I suspect this is the root of our problem
I'm considering these two approaches:
Add new properties to the control that will return information about the currently selected box(es). e.g. text in the box, position on screen, hierarchical path, and access them via TestCompletes debug agent.
Look at creating a custom control add on for TestComplete (I'm not even sure you can do this with Delphi controls)
The problem with the first approach is the linker will often elimate properties and functions if they are not being used. We want to use our release build for testing not a debug build.
Does anyone have any advice on this or experience with this type of thing?
Thanks
Edit: I've just read the SDK help and custom control addons can only be created for .net and WPF controls.
You are right about the debug info - you can strip it out from the release build. Thus, you will test a release build and have access to internals at the same time.
A note regarding this situation: "the linker will often elimate properties and functions if they are not being used." You can cheat here to make the linker generate debug info for those funcitons:
Make the funcitons published. The linker does not touch published elements.
Make the funcitons virtual. The linker does not exclude virtual methods.
Call your functions somewhere in your code. To include the call in your code without actually calling anything, you can do something like this:
var t: Boolean;
begin
t := False;
if t = True then
TheFunctionThatNeverExecutes();
...
end;
You should reconsider your decision to use the release build for testing. The reason is that TestComplete needs some magic to make your testing life easier while you don't want this magic be present in the release build. So if you can elaborate on the reasons for not using a debug build for testing, we can try to find a solution to revoke this decision. The result may be that you will have access to all the relevant data of your control if you only reveal all available power of TestComplete.
Now back to the original question: You can overcome the interfaces problem by creating some special classes that wrap those interfaces and thus make the properties available in TestComplete.
Create a small (perhaps invisible) test form where you centralize access to instances of these classes. (Now the release mode link) Only create this form in debug mode so, when carefully designed, you only link in the relevant code when needed for testing.