I have a program create by Delphi language. This run on windows XP SP3.
After Open and stop program multi time (~600 to 700 times) (Only open and stop, does not do any thing). My program will be error:
Cannot input to text box of system.
Cannot click on some button.
When bug has occurred, the error will exist until the computer is restarted. (Restart program cannot resolve this bug)
I was check some information of system, and bellow is result:
Total GDI handles is less than GDI handles in normal: (Use GDIView to detect that)
case normal: 3513 GDI handles
when error occur: 3410
Class Name of control is bad: (Use spy++ detect)
Normal: Class name of text box is Tedit.
When error occur: "Toolbar_Customize" or "" or any value (This value is awlay change) ==> I think because that, i cannot input value to textbox.
Some time, i cannot start another program of windows when this bug occur.
Please help me.
P/s: any unclear please comment
This reminds me of the following issue (Resource leak caused by RM_GetObjectInstance message):
http://qc.embarcadero.com/wc/qcmain.aspx?d=90511
There is a workaround in the last comment.
Related
when i compile my code i can see that some lines are not compiled. Due to this issue some codes does not execute according to the way i want.
i have attached a screenshot of the delphi IDE in the debug mode. Blue dots on the left shows the lines which are compiled and those lines without the blue dots does not function properly or not complied
As can see on the watch window that variable dPcnt value is 0 taxP, srvP, serv_charge does not have a proper value but in the code window can see that the variables have been initialized to 0
Can someone help me out to correct the issue.
It is the optimizer that has removed useless lines like
srvP := 0;
because you don't use that value before you assign a new value on line 770.
I can not see how and where the other variables are used, but I bet the reason is similar.
You can turn optimization on and off with the compiler directive {$O+} or {$O-} {$OPTIMIZATION ON} or {$OPTIMIZATION OFF}. But, please note what help says about it:
Other than for certain debugging situations, you should never have a
need to turn optimizations off. All optimizations performed by the
Delphi compiler are guaranteed not to alter the meaning of a program.
In other words, the compiler performs no "unsafe" optimizations that
require special awareness by the programmer.
If you have compiler hints turned on ({$HINTS ON}) you will see hints in the form H2077 Value assigned to '%s' never used for lines that are 'useless'.
Further info here:
H2077 Value assigned to '%s' never used #Delphi#
Hi I am using LabView 2012, Delphi XE7 and GPIB (I think 488.2), Win7 SP1 and Agilent 53131A.
I used the given NI examples.
NI Labview example - Found in LabVIEW's help - GPIB.vi.
I tried writing and reading to query frequencies from 2 channels and they are successful.
They are are sent and read in succession.
*IDN?
:FUNC 'FREQ 1'
:READ:FREQ?
If they are successful, that meant GPIB for Agilent and NI MAX and driver are successfully installed and configured.
I am also able to use KeySight Connection Expert's to write and read, Again it is also successful.
However, When I used the given NI example in Delphi. Orginally it was saved as Delphi 3 or 4.
I used the Scope Simple example for universal counter. I used it mostly for writing and reading in the simple way. All it needs initialization, read/write and cleanup
I changed the following codes as shown below, in SimpleForm.pas
The detected device is at GPIB0::3::INSTR so, at line 32,
PRIMARY_ADDR_OF_COUNTER = 3;
String to write and read so, at line 132,
CommandBox.Text := '*IDN?';
then it was compiled with no error and run.
String to write was successfully
But upon reading, it was not successfully.
The string output is supposed to be ' HEWLETT-PACKARD,53131A,0,4806'.
The error at the end of the program is as follows below:-
Unable to read from device
ibsta = SC000 <ERR TMO>
iberr = 6 <EABO>
ibcntl = 0
From these readings, I figured out as :-
EABO means abort
I am not familiar with working of GPIB. Kindly advise.
You are correct that EABO is the identifier for an abort. In addition, we can see from ibsta = SC000 <ERR TMO> that the cause of the abort was a GPIB timeout error. I am not familiar with Keysight Connection Expert or your instrument, but since the error was from GPIB timeout, the most likely causes are:
The query was improperly formatted and the instrument thought it was just a write statement with no response needed. (That's probably why the write function had no error, but the read function timed out.)
The query was improperly formatted and the instrument returned an error.
Instrument needs to have 'Talker' capability enabled to send data. (Most instruments do this automatically with queries.)
For more information on generic GPIB commands, see this reference from the folks at National Instruments.
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
I'm having trouble with the dmColor field fo the DEVMODE structure.
My default printer is a color printer, if I default output color of the printer properties through the control panel to black and white the DEVMODE.dmColor field always returns DMCOLOR_COLOR instead of DMCOLOR_MONOCHROME.
Even if I default my printer to a black and white only printer, DEVMODE.dmColor still always returns DMCOLOR_COLOR
All of the other DEVMODE fields such as dmDeviceName, dmCopies, dmDuplex, etc work fine. I have also tried to query DC_COLORDEVICE using the DeviceCapabilities function, microsoft documentation says it should return 1 if the device supports color, 0 if it does not and -1 if an error occured. This function is always returning -1 but the error code returned by GetLastError translates to "The operation completed successfully".
I'm running under windows Vista and I have specified DM_COLOR in DEVMODE.dmFields, does anyone know why this happens?
I've solved the issue, it seems like the color setting along with other settings are stored in the private drive data section below the DEVMODE structure. The size of the private data is stored in DEVMODE.dmDriverExtra. Copying the private driver data returned from the printer properties dialog box to the printing device has fixed the problem.
This might be a driver issue.
I'm having the exactly opposite on my HP 2840 color multifunctional: the XP specific drivers work well (allowing both color and monochrome), but they are not supported on Vista and higher.
From Vista on, you need to use the Generic HP drivers, which always return monochrome.
--jeroen