One of the used references for my code is Refprop which includes required functions such as Temperature. In debug mode, there isn't any problem, but when outside the vb I run the code there is a "type mismatch" error to calculate TR_O_P_Com.
Option Explicit
Sub Simulation()
Sheets("Sheet1").Activate: Range("A:ZZ").Select: Selection.ClearContents
'
TR_O_P_Com = Temperature("R134A", "HP", "si", HR_O_P_Com / 1000, PR_S_P_C) - 273.15
and when I use F8 in debug mode there isn't any problem! I have declared all of the variables such as HR_O_P_Com and TR_O_P_Com.
I am so grateful if you help me to remove this error.
Regards
Seems like dll and exe has different method signature. For example in dll method A(int a, int b) and in exe you are calling with A(int a, char c). But not sure. Use all the latest dll and exe after the compilation and try again.
Did you compile the code in release mode? First use the exe that has been generated in debug mode out side of vb. If that works fine then try with the exe in release mode.
Related
I work on image processing application in Embarcadero C++ Builder XE10.2 that executes Lua scripts. I use LuaJIT with FFI to share image data. Everything works fine. I've downloaded ZeroBrane studio and tried to see if I can debug scripts executed from "host" C++ application, so I've included
package.path = package.path .. ";C:/Portable_App/ZeroBraneStudio/lualibs/mobdebug/?.lua"
package.cpath = package.cpath .. ";C:/Portable_App/ZeroBraneStudio/bin/clibs/?.dll"
require("mobdebug").start()
before any function in the script is called. However, when the script is loaded and executed (on C++ side):
FResult = lua_pcall(FLs, 0, 0, 0);
host program crashes with "floating point division by zero" exception. It crashes on
require("mobdebug").start()
Without this line script works OK. Any clue?
It's not possible to tell what may be going wrong based on the provided information, but you can try to get the stack trace (using this SO answers), which should provide more information about what's leading to the error.
The only division that I'm aware of is in the serialization code that uses tostring(1/0) code to generate platform-independent NaN values. Would this lead to "floating point division by zero" error in your Lua configuration?
(Update to include the solution mentioned in comments) The issue was related to BCC compiler settings on how to handle FPU exceptions. One way is to manipulate FP control: _clear87(); _control87(MCW_EM, MCW_EM); or to set arithmetic exception mask: SetExceptionMask(exAllArithmeticExceptions);.
I'm just learning F#, and setting up a FAKE build harness for a hello-world-like application. (Though the phrase "Hell world" does occasionally come to mind... :-) I'm using a Mac and emacs (generally trying to avoid GUI IDEs by preference).
After a bit of fiddling about with documentation, here's how I'm invoking the F# compiler via FAKE:
let buildDir = #"./build-app/" // Where application build products go
Target "CompileApp" (fun _ -> // Compile application source code
!! #"src/app/**/*.fs" // Look for F# source files
|> Seq.toList // Convert FileIncludes to string list
|> Fsc (fun p -> // which is what the Fsc task wants
{p with //
FscTarget = Exe //
Platform = AnyCpu //
Output = (buildDir + "hello-fsharp.exe") }) // *** Writing to . instead of buildDir?
) //
That uses !! to make a FileIncludes of all the sources in the usual way, then uses Seq.toList to change that to a string list of filenames, which is then handed off to the Fsc task. Simple enough, and it even seems to work:
...
Starting Target: CompileApp (==> SetVersions)
FSC with args:[|"-o"; "./build-app/hello-fsharp.exe"; "--target:exe"; "--platform:anycpu";
"/Users/sgr/Documents/laboratory/hello-fsharp/src/app/hello-fsharp.fs"|]
Finished Target: CompileApp
...
However, despite what the console output above says, the actual build products go to the top-level directory, not the build directory. The message above looks like the -o argument is being passed to the compiler with an appropriate filename, but the executable gets put in . instead of ./build-app/.
So, 2 questions:
Is this a reasonable way to be invoking the F# compiler in a FAKE build harness?
What am I misunderstanding that is causing the build products to go to the wrong place?
This, or a very similar problem, was reported in FAKE issue #521 and seems to have been fixed in FAKE pull request #601, which see.
Explanation of the Problem
As is apparently well-known to everyone but me, the F# compiler as implemented in FSharp.Compiler.Service has a practice of skipping its first argument. See FSharp.Compiler.Service/tests/service/FscTests.fs around line 127, where we see the following nicely informative comment:
// fsc parser skips the first argument by default;
// perhaps this shouldn't happen in library code.
Whether it should or should not happen, it's what does happen. Since the -o came first in the arguments generated by FscHelper, it was dutifully ignored (along with its argument, apparently). Thus the assembly went to the default place, not the place specified.
Solutions
The temporary workaround was to specify --out:destinationFile in the OtherParams field of the FscParams setter in addition to the Output field; the latter is the sacrificial lamb to be ignored while the former gets the job done.
The longer term solution is to fix the arguments generated by FscHelper to have an extra throwaway argument at the front; then these 2 problems will annihilate in a puff of greasy black smoke. (It's kind of balletic in its beauty, when you think about it.) This is exactly what was just merged into the master by #forki23:
// Always prepend "fsc.exe" since fsc compiler skips the first argument
let optsArr = Array.append [|"fsc.exe"|] optsArr
So that solution should be in the newest version of FAKE (3.11.0).
The answers to my 2 questions are thus:
Yes, this appears to be a reasonable way to invoke the F# compiler.
I didn't misunderstand anything; it was just a bug and a fix is in the pipeline.
More to the point: the actual misunderstanding was that I should have checked the FAKE issues and pull requests to see if anybody else had reported this sort of thing, and that's what I'll do next time.
I'm trying to execute a simple erlang program of adding two numbers.
I'm trying to do this in Eclipse on Ubuntu 10.04 LTS.
When i execute this program, I'm getting the error as shown below:
** exception error: undefined function add:addfunc/0
How do i go about solving this error? Thanks in advance.
This program when executed in the erlang shell is working fine. But when it comes to eclipse it's giving me this error. Not this, any program for that matter is giving me the similar error. Guess I would be missing something about the eclipse configuration.
EDIT:
Anyways, This is the sample add program,
-module(add).
-export([addfunc/0]).
addfunc() ->
5 + 6.
This message tells you that module add doesn't have an exported function addfunc/0.
Ensure the function you want to be called has exactly that name, doesn't expect any
parameters, is
exported, the module is
compiled, the search path includes the compiled beam file and that there is no module clashes using code:clash()
Update
It's not clear how erlide (eclipse erlang plug-in you seem to use) compiles and runs a program. Try to compile source using erlc or inside erl shell. That way you'll have much easier controllable environment and you'll better understand what's going on.
I got exactly the same problem -for a tail recursive fibonacci function- below:
-module(math2).
-export([fibonacci/1]).
fibonacci(0) -> 0;
fibonacci(1) -> 1;
fibonacci(M) -> fibonacci(M-1) + fibonacci(M-2).
In the end, had realized that this is a compile-time exception. Then, have opened a new tab on my shell and tried with erlc, instead of erl.
$ erlc math2.erl
Now I am also able to see math2.beam file created.
Called fibonacci with 10:
4> math2:fibonacci(10).
55
and it worked!
I think you have not compiled the code and you are trying to run the program.
In eclipse, using the "Run" icon, trigger the run; which will get you to the erl shell in the console window.
There you do -
cd("C:\Learning_ERL\src").
And you should see output like-
(Learning-ERL#DALAKSHM-MNFSM)7> cd("C:\Learning_ERL\src").
c:/Learning_ERL/src
ok
Then compile the code -
c(add)
you should see something like this on the erl shell-
(Learning-ERL#DALAKSHM-MNFSM)10> c(add).
{ok,add}
Now you should be seeing a new file called - add.beam in the same directory as that of your erl source file - add.erl
add.beam is a bytecode file
Now you should be able to run the program without any error
How do you try to execute your code?
In your editor, right-click and choose "Run as"->"Erlang application". The VM that is launched will have your project loaded automatically and when editing/saving a file it will get reloaded. When launching, a console appears and you can call your code from there.
If it still doesn't work, what message do you get for m(add).?
I am debugging a DirectShow filter I created with the DSPACK code library using Delphi 6 Pro. When a breakpoint I set is hit in one particular unit named BaseClass.pas, and I begin tracing, the Execution Point jumps to strange places in the source code. This usually indicates that the source code being traced does not match the source code that was compiled into one of the packages being used by the Delphi application. Oddly enough it is only the BaseClass unit since I have traced other units belonging to the DSPACK code library and they do not exhibit this problem. I am not using run-time packages.
I scanned my disk and found only one copy of BaseClass.dcu with a modification date equal to the last time I built the program. I have not modified the source for that unit or any other belonging to DSPACK. Since my Filter is part of the main application this indicates that BaseClass.pas would be subject to a dual use situation since it is used to build the DSPACK component package (dpk), and is also referenced by my main application directly via the TBCSource object my Filter descends from. Note, I did try adding the unit PAS file directly to my Project but that didn't fix anything.
I also went back and re-opened each of the DSPACK package files and did a full re-build. None of this helped. Is there something else I can try to get the source synchronized with the compiled image of the BaseClass unit? Or is a different problem altogether and if so, what is it and how can I fix it?
Sometimes this happens when code is copied/pasted from web pages or other sources, and the lines don't end with CR/LF pairs (#13#10 or 0x0D0A, standard for Windows) but end in only LF (#10 or 0x0A, typically the line ending in *nix systems) or CR (#13 or 0x0D, typical with Mac OSX/iOS). The incorrect line terminators confuse the debugger - this has been an issue for the past several Delphi versions.
You can sometimes fix this by opening the source file using a text editor like Notepad, making a small meaningless change (insert and then delete a blank line, for instance), and then save the file.
I had same problem and made a similar utility. Fixed it.
Basically, just this:
procedure adjustCRLF(filename : String);
var
strList : TStringList;
begin
strList := TStringList.Create;
try
strList.LoadFromFile(filename);
strList.Text := AdjustLineBreaks(strList.Text);
strList.SaveToFile(filename);
finally
strList.Free;
end;
end;
There is another way this can happen: if the IDE erroneously opens another source file with the same name (but different, such as an earlier version) then all the debug points will be incorrect, and the debugger will even allow you to step through the incorrect file.
I've seen Delphi 7 do this once.
Make sure that when you rebuild it, that in the compiler options for your project that you have "Debug Information" turned on. In fact, most of the options under Debugging should be set in your project's Compiler options.
Also, if you haven't already, restart Delphi.
I have searched for hours but could not find anything similar.
The crash has two flavors; one is with "Run-time error '-2147418113 (8000ffff)' Method '~' of object '~' failed" and the second flavor is a total crash where Windows asks if I want to report this to Microsoft. In the second case I chose to debug once and it showed "Unhandled exception in App.exe (OLEAUT32.DLL): 0xC0000005: Access violation."
The Disassembly screen showed the yellow pointer at top line of:
>> 771148A4 mov ecx, dword ptr [esi]
771148A6 add ecx, 15h
771148A9 and ecx, 0FFFFFFF0h
771148AC push ecx
771148AD push esi
...
The problem occurs when calling a particular essential function in a third-party Delphi DLL, but I cannot declare outright that the DLL is buggy because this happens only in the program executables I compile. This same dll is used in hundreds of other customers and (at least for now) I am the only one running into this problem. The same source code compiled in the customer's PC, or the 3rd party supplier's office works fine.
So the problem boils down to this: VB6 with SP6 produces different binary exe files from the exact same source code. The one compiled on my pc works fine in my pc, and a clean virtual pc I installed to check this, but does not work anywhere it should; and the one compiled in the customer or the 3rd party supplier works fine everywhere except my pc.
It is unlike the problem Boost describes (see this link) since both the IDE and the compiled application behave in the same manner on all machines. They either work fine or break terribly.
Public mXApp As XObjects.XApplication
Public Sub Main
On Error Resume Next
Set mXApp = New XObjects.XApplication
If Err.Number = 0 Then
MsgBox "Found: " & mXApp.Version & vbCrLf & mXApp.GetAppPath
Else
MsgBox "XApp DLL not found. " & Err.Number & ": " & Err.Description
End If
Err.Clear
End Sub
Public Sub Login(Byval uid As String, Byval pwd As String, Byval companyNr as Long)
Dim ok as Boolean
ok = mXApp.Login(uid, pwd, companyNr)' >> CRASH! Program never gets to the next line.'
If ok Then
MsgBox "Login success"
Else
MsgBox "Login fails"
End If
End Sub
Note that after the mXApp object is created, two function calls are done -namely Version and GetAppPath- without any problem. The crash occurs in the Login call. VB IDE Object browser displays the definitions of the three functions as:
Function Version() As String
Function GetAppPath() As String
Function Login(UserName As String, Password As String, FirmNr As Long) As Boolean
Does anyone have any solutions or (equally usefully) ways that I can make the supplier reproduce this problem in their own machines?
Well, it's hard to say for sure without being able to see the Delphi side of it, but when you get problems like this in DLL calls, there are two standard things to check first.
First, make sure the DLL function and the import header for it in the VB program are using the same calling convention. If VB is putting the paramters in one place and the Delphi DLL is looking for them somewhere else, you get undefined behavior.
Second, make sure you're using the same string type on both sides. If this is COM, your string type should be the COM BSTR type, known as WideString in Delphi. Not sure what VB calls it. If you're passing the DLL a different string type than it's expecting to receive, it'll get corrupt data.
Double-check these two things and see if that doesn't fix it.
Problem Solved! Mason was quite right when telling me to double-check:
...make sure the DLL function and the
import header for it in the VB program
are using the same calling convention.
If VB is putting the paramters in one
place and the Delphi DLL is looking
for them somewhere else, you get
undefined behavior.
The DLL on my pc and the one in the customer were slightly different builds all along. And I had assumed that they had exactly the same interface. But wait before thinking I was careless; I did not just assume this, I had compiled two different executables after registering both versions of the DLL long before posting my question here.
When I thought I had tried the second dll, I was mistaken. I had registered the dll version 1.1 on my pc. The Object Viewer showed the declarations in the question. I compiled the executable and tested. And then without exiting the IDE, I registered the dll version 1.2 and compiled again assuming that the VB compiler would read the dll interface during compilation. Well this assumption was wrong. It turns out that the IDE had to be restarted.
Problem was solved after the supplier of the dll told me there was an optional new parameter, but they did not mention it earlier assuming this would not be problem since it was optional.
Below is the difference that caused the crashes:
Function Login(UserName As String, Password As String, FirmNr As Long, [PeriodNr As Long]) As Boolean
Make sure you're loading the right DLL. Process Explorer from SysInternals will show you the DLLs being used by any app (configure it to show DLLs in the lower pane). Maybe you're loading a different version of the DLL, unknowingly.
You can run it directly here:
http://live.sysinternals.com/ click on procexp.exe