I am having an issue with displaying a shared variable from subreport on main report. I declared a shared vaiable in subreport as
Shared NumberVar avalue ;
avalue :=Count ({ActivityReport2.IPD})
It shows a value of 14 in the subreport.
and in main report it is referenced as
Shared NumberVar avalue;
avalue;
When I try to use it in the Main report it just shows value = 0.00.
Please help :)
I am not sure but can you try doing like this:
Shared NumberVar avalue :=Count ({ActivityReport2.IPD})
Instead of declaring and then using the same.
And use in the main report as:
Shared NumberVar avalue;
Place your formula in subreport in which you have declared your shared variable and it will reflect in your main report.later you can supress your details in subreport.
I hope this will help you
Related
What the program does
I have a function that dynamically generates a table and populates it. So...
What's the problem?
The problem is that i've tried looking for a way to edit a specific column properties by code since I can't (Obviously) use the normal properties Editor in delphi, but I've haven't had any success so far.
Here's what I've tried SO far:
for I := GridOrdiniMagazzinoPadreView1.ColumnCount - 1 downto 0 do
begin
GridOrdiniMagazzinoPadreView1.Columns[I].Destroy;
end;
GridOrdiniMagazzinoPadreView1.DataController.CreateAllItems;
GridOrdiniMagazzinoPadreView1.Columns[0].PropertiesClassName := 'CheckBox';
It doesn't show the CheckBox, I know it shouldn't do anything since i didn't set the checked status and neither how to recognize the String to set it as checked or not checked. But i expected at least to see the checkBox.
You are setting the wrong classname, passing 'TcxCheckBoxProperties' will work:
GridOrdiniMagazzinoPadreView1.Columns[0].PropertiesClassName := 'TcxCheckBoxProperties';
Anyhow, I always prefer to set the PropertiesClass property, instead of the PropertiesClassName property:
uses
cxCheckBox;
...
GridOrdiniMagazzinoPadreView1.Columns[0].PropertiesClass := TcxCheckBoxProperties;
Well, here I am again, trying to resolve an old problem.
Briefly, I get an AV when I try to free a modal form which does not have any owner, and didnt have been freed before.
frmItensVenda := TfrmItensVenda.Create(nil);
frmItensVenda.vtipo := vtipo;
frmItensVenda.vcontrole := strtoint(edit1.Text);
frmItensVenda.Ednota.Text := Edit5.Text;
frmitensvenda.lbvend.Caption := combobox3.Text;
frmitensvenda.lbnome.Caption := combobox1x.Text;
frmItensVenda.limite := limite;
if label10.caption <> '' then
frmItensVenda.vcli := strtoint(label10.caption);
frmItensVenda.ShowModal;
Frmitensvenda.Close;
frmItensVenda.Free;
If I just activate it and then close(without doing a thing), no AV happens. Putting a break-point before the 'free' command, it shows me the variable inside the form if I put the mouse cursor on it.
But if I insert one item in the grid, using the breakpoint at the same place, when I move the cursor to the same line, it doesnt show the variables anymore, but says 'inacessible value'.
And if I proceed running the code, as the next line has the 'free' command I get an AV.
What makes me believe there is some piece of code on that procedure that is doing something unexpected to the code, but I can tell you that there is no 'free' or similar command to the form in question there.
My solution(temporary) was to just comment the '.free' command, but if I run MadException I got a memory leak when I close the application (hey, anything is better than this EAccessViolation thing for me right now..)
Any sugestions?
Ok, found the answer, finally.
The problem was a global array.
It was declared
vm1 : array[1..100] of currency;
but it was assigned a value at position 0.
To my despair, there was no error when the variable was assigned, just when I tried to free the form.
So simple when you find it.. (!!!)
Well, at least I figured it out. Thanks everyone for the support!
OP : frmItensVenda is a global variable automatic created(but not initialized).
I see you do frmItensVenda := TfrmItensVenda.Create(nil);
Look for Application.CreateForm(TfrmItensVenda, frmItensVenda); in your .dpr file.
If it is there you creating a new instance !
{$R *.RES}
begin
Application.Initialize;
Application.Title := 'AServer';
...
Application.CreateForm(TfrmItensVenda, frmItensVenda);
...
Application.Run;
end.
And yes, dynamic form management is a must really (expecially in large applications.).
At trouble with large Forms, part of my solution was to, as much as possible to create dynamic.
Only when they are needed and then free them straight after.
frmItensVenda := TfrmItensVenda.Create(nil);
frmItensVenda.ShowModal;
OP : My solution(temporary) was to just comment the '.free' command,
don't do that : use instead
frmItensVenda.Release;
The "Method Release" removes the form and frees its associated memory.
Release procedure;
description
With release, you can remove the form from memory.
Release is the form to be taken until after the execution of event handlers of the form and its child components is completed.
In all event handlers release should be used instead free to avoid access violations.
The cases where you need to use Release are times when you're in the middle of an event handler (eg, OnClick), where further processing after the event will have to access the form.
In that case calling Release instead posts a WM_RELEASE message which doesn't free the event until the event handler is done and control has returned to the message pump (ProcessMessages/Application.Run).
Reading the delphi help though, it is recommended that you use the release command.
As for the Release v.s Free method. My understanding is that "Release" is specific to forms, and allows form-related even-handlers to finish before freeing resources.
Whereas "Free" is a generic method of freeing an object from memory (so should also work with forms.)
My company has a large selection of templates which are used to generate customer correspondence. I need to modify the existing processes so that copies of generated files (template + data) are saved for later editing.
My problem is that when I open one of these saved MSWord documents, edit, then close, MSWord is insisting that changes have been made to the template (the one selected in the generation process).
I am not really sure why this is happening, but it may be that the generated document contains a reference to the template upon which it was based, but that because the template is in a remote location, MSWord is attempting to generate a new local file.
If that diagnosis is correct, then I need a method to remove the template reference from the document.
If the diagnosis is incorrect then what is the likely explanation/solution?
I have found that BOTH resultant files contain a reference to the template.
Note: Manual editing in Word has no issue. If I let the letter generate and save to disk from Winword, I can open it and manipulate it quite happily. Somewhere in the automation steps the problem is being created.
Interestingly - I have changed the save format to '.rtf' and the problem remains.
Further - it doesn't matter if I say 'Yes' to saving changes to the template, it continues to prompt me each time I open and close the document (whether I edit or not)
I have discovered that by saving the document as wdFormatXML I can see the reference to the letter template and edit it. If I do that the problem goes away.
I am now attempting to achieve the same result via automation, but with no success;
WordApp.ActiveDocument.Set_AttachedTemplate(tmplt);
Does not work for values of tmplt 'Normal.dot', varNull, 'c:\progra~1\etc\Simple.dotx' and so on. The function call tells me it cannot find the template for the first 2 of those values, or merely hangs.
I am back to my original question - how does one clear the attached template ?
I eventually figured it. My problem was down to late-binding in some way. I found that the following code worked
var
docpath : OleVariant;
fmt : OleVariant;
tmplt : OleVariant;
WordApp : WordApplication;
WordDoc : WordDocument;
begin
docpath := SaveLoggedDocToDisk(GetCurrentFileName());
WordApp := CoWordApplication.Create;
try
fmt := EDITABLE_FORMAT;
tmplt := '';
WordDoc := WordApp.Documents.Open(docpath, EmptyParam, EmptyParam, EmptyParam, EmptyParam, EmptyParam, EmptyParam, EmptyParam, EmptyParam, fmt, EmptyParam, EmptyParam );
WordDoc.Set_AttachedTemplate(tmplt);
The problem I had with earlier versions of this code was that
WordApp.ActiveDocument.SetAttachedTemplate(tmplt);
although it appears equivalent, was not behaving. By creating a variable of type WordDocument the routine sprang into life.
I'm writing an IDE for DWScript and have got it stepping through code using the debugger. I now wish to add a display of 'local variables' (i.e those in scope). Can someone give me a pointer to the means of doing this? I can get a list of all symbols but do not understand how to get the current scope part of things.
Thanks.
Cast the IdwsProgramExecution to TdwsProgramExecution, you'll gain access to a "CurrentProg", property, a TdwsProgram which is either a TdwsMainProgram (if you're in the main) or a TdwsProcedure (if you're in a proc/func/method). Those will have a Table property, which lists the local symbols, that's the most direct scope.
That Table will have one or more Parents, which refers the parent scopes (hierarchically, in terms of source code scope).
If in a TdwsProcedure, you may also want to look at its FuncSymbol property, which will have a table of parameters (useful if you want to directly isolate the parameters from the rest of the local scope)
For any others reading this question, I will show some supplementary info concerned with getting the value of a symbol. The symbol is found as described by Eric above but it is hard to work out how to get the actual value of the symbol. The code below is a procedure that populates a TMemo (memLocalVariables) with local variables each time it is called. There are some features missing like neat formatting of the variable value and access to calling parameters. I call this from the debugger 'dsDebugSuspended' state. The less intuitive bit is the access to the symbol data on the stack and the use of the stack base pointer. A great way to learn how the compiler works! But, maybe there is a utility function somewhere I've not found...? Eric?
procedure DrawLocalVariables;
var
ProgramExecution : TdwsProgramExecution;
I : integer;
Sym : TSymbol;
V : variant;
Adr : integer;
SymbolTable : TSymbolTable;
begin
memLocalVariables.Lines.Clear;
ProgramExecution := TdwsProgramExecution( dwsDebugger1.Execution );
SymbolTable := ProgramExecution.CurrentProg.Table;
For I := 0 to SymbolTable.Count-1 do
begin
Sym := SymbolTable[I];
if Sym is TDataSymbol then
begin
Adr := TDataSymbol( Sym).StackAddr + ProgramExecution.Stack.BasePointer;
ProgramExecution.Stack.ReadValue( Adr, V );
memLocalVariables.Lines.Add( Format( '%s = %s', [ Sym.Name, VarToStr(V) ] ));
end;
end;
end;
What's so special with Frames that when you create them run-time it gets assigned a name automatically ? This causes a problem when you use them in a loop i.e. :
for i := 0 to 3 do
TMyFrame.Create(self); //Error on 2nd pass
On first pass, the frame is explicityl named 'MyFrame'.
On second pass, it will try to name it again 'MyFrame' which
obivously will cause an exception as there is already a
component with such name.
The other components or forms are happy to be created without
me assigning them a name. What gives ?
This is on Delphi 2006 btw.
Cheers
If you are using TFrame to create your Frame, then it wont raise that error.
i.e., If your code looks like this, you wont have any problems
for i := 0 to 3 do
Frame1 := TFrame.Create(self);
because here the Name property is unassigned. If you want you can check by using the statement ShowMessage(Frame1.Name);
But if you use TMyFrame i.e., the frame which you derived from TFrame, then it will giving the problem.
I think the reason is, Delphi was explicitly assigning the same Name every time you create the TMyName.
you're trying to create the same frame 4 times, each time you create the frame it will have the same name, one way to avoid is
...
var
i: Integer;
lFrame: TFrame;
begin
for i := 0 to 3 do begin
lFrame := TFrame.Create(Self);
// assign a unique name to the frame
lFrame.Name := Format('MyFrame%d', [i]);
// set the parent, align, etc...
end;
end;
Co-incidentally I just bumped into this myself (again).
If you take the name out of your frame component then Delphi moans that "Root Component must have a name" - I guess it because somewhere Delphi is calling RegisterClass(RootComponentName) and then to create it (or a descendent) it's calling Findclass(RootComponentName) or similar. As you can do this yourself to create components that you don't actually know the classname of a design time, why would Delphi not do the same?
Whereas with a TButton etc. it is already a registered Class.