I am trying to convert some inline polymer templates for grid columns, and the rendered value in the browser ends up as “NaN” for some reason.
So I simplified the template to reproduce the issue as the following:
grid.addColumn(LitRenderer.<SamplePerson>of("<span style='${item.stylename-0}'> test </span>")
.withProperty("stylename-0", dto -> "background-color: red"));
and the rendered value still says style="NaN". Is there something that I’m missing?
Steps to reproduce the issue:
Go to https://start.vaadin.com and add a Master-Detail view from the existing templates to the views.
Download the application and open it in your favorite editor.
in the com.example.application.views.masterdetail.MasterDetailView's constructor, add the column with a LitRenderer (you can copy the above snippet code as well).
Run the application, go to http://localhost:8080 and observe that the values for the manually added column hasn't been styled with a red background. Obviously, by inspecting the elements you could see the style="NaN" is rendered on the client.
Tested with V23.2.3 and V23.2.4 and the issue exists.
Nicely spotted by #leif-Åstrand, this was an issue regarding the -0 ending, which was being parsed as a mathematical subtraction in JS, and clearly resulting in "NaN".
The correct way of doing this kind of dynamic class or style values ("stylename-0", "stylename-1", ...) is to treat them as strings, so:
style='${item.stylename-0}'
should be written as
style='${item['stylename-0']}'
I have a function that prints a report for each selected item in a grid.
If I use preview without prepare it works but if I use prepare only the first report is printed. All the rest gives an empty report.
I create the report dynamically also the dataset is created dynamically. All components are freed at the end and recreated at the next report.
If I print all items one by one it works.
What happens in the prepare function, what can I do to avoid this?
I use FR5 and Delphi XE6 on windows10
If you create composite report - call TfrxReport.PrepareReport(True) on the first loop, TfrxReport.PrepareReport(False) on the next loops
I am using FastRepors v4.11 which comes with Delphi XE2
Is there a way I can set the text for a MemoView dynamically using nested expressions
I tried a couple of different ways but none seem to work
[ReportHeader."Ch[ReportHeader."Channel"]Label"]
[ReportHeader."Ch<ReportHeader."Channel">Label"]
<ReportHeader."Ch[ReportHeader."Channel"]Label">
[ReportHeader."Ch" + [ReportHeader."Channel"] + "Label"]
Channel holds a value like 1 or 2 or 3 or 4. I want the MemoView to display the evaluated value of CH1Label or CH2Label etc
So if ReportHeader.Channel = 4 then the value of [ReportHeader."Ch4Label"] should be rendered inside the MemoView
**Setting the text for MemoView dynamically in my Delphi code, before the report is printed works but I am wanting to simplify the code by moving this logic to FastReports
Fast Report's expression parser does not support nested expressions in the way you are trying to use them. As you only have the bundled Embarcadero version of Fast Reports, your only solution is to modify the memo view directly in your Delphi code or create a calculated field for the memoview component.
The paid for version of Fast Reports (Standard and up) support event handlers and scripting at the report component level, so if you wanted to keep the display logic in your report, then you could use scripting and use the OnBeforePrint event of the MemoView in question within the Fast Reports designer.
I'm working in a Delphi IDE expert and I wonder if it's possible add new items to the code completion combobox displayed by the Delphi IDE when the user press CtrlSpace
UPDATE:
What I need is add items to the code completion list based in a specified type.
example suppose which I have a type called TMytype, what I want to do is add addional items to the code completion list when the user type a variable of the type TMytype
check this image
I found your question somewhat confusing but if you are in search of credible source on "Custom Live Templates" and the like on Delphi, head to the blog of Cary Jensen here.
Edit:
Looking forward to further improvement of the scope of the question, I suggest here another direction to explore:
Source code manipulation using IOTAEditor, IOTASourceEditor, IOTAEditReader and the like
Some Parsing for sanity check prior to apply any modification.
Adoption of Client DataSet as a format to store data (It's serializable) to simplify the coding of IDE editors.
Perhaps I haven't fully grasped the extent of what you are asking here, but you can add templates simply by going to 'View|Templates' from the Delphi IDE. This then opens a template viewer. Press the '+' icon. It opens a template1.xml document which you can then edit so create your new item.
If you wish to do this programatically, just add an xml file (of the same format) to the ..\RAD Studio\code_templates folder.
I am getting a cascading set of "EClassNotFound" errors in in my Delphi 2007 project. Doesn't seem to be caused by the missing Name property value as often is the case, and though adding RegisterClass(XXX) in the initialization section(s) fixes the EClassNotFound error at hand, another one follows it seemingly indefinitely.
I finally cracked open the DFM file in text editor, and it looks likely corrupted to me (lots of non-ASCII characters amidst form element names, and very "unstructured" looking when compared to what I'm used to seeing in a DFM file). (I'd post a same here but not sure that's OK, w/the non-aSCII, so will hold off).
The form loads fine, and seems to compile / syntax check OK too, but once I run it, trouble.
Going back to early versions of it in SVN, it looks like it's been in this state for some time, which makes me think that either A) the DFM file isn't my problem, or B) the Delphi form-streaming is quite fault-tolerant/robust (Bonus Question: Which is it?).
If the DFM file is the problem, and is corrupted, rolling back will have to be a roll-back WAY back, and that's gonna be expensive. Given that the IDE can still load it, is there any utility that can clean up the file?
Or, am I totally off base w/the DFM as primary suspect?
Thanks folks for the input. Forgot about the binary/text options w/DFM files, so that was helpful. It looks like the DFM itself is not corrupted.
Still having the EClassError issue though. re: It being missing property values, or referencing non-existing properties, etc., a further question: Is the class the error is given for (currently TnxSqlUpdateObject, but probably more waiting in the wings if experience thus far is consistent) usually/always the actual "culprit" class/object?
For instance, right now my main form has four references to TnxSqlUpdateObject, w/those actually dropped on the form. If I put RegisterClass(TnxSqlUpdateObject) in the initialization section, it runs fine for that EClassNotFound error but then goes on to the next one (in this case, TStringField).
I have reinstalled the NexusDB components in this case, and also built a new project using some of the components I thought might be the problem. It compiles and runs fine, UNTIL I add this other form from my real project (which, in turn, unfortunately references quite a few others).
SO, it sounds like my real issue is how to methodically diagnose and fix any and all EClassNotFound errors?
I get this error if a component is on the form, but doesn't have an entry in the form definition in the source file too. Most often when I've copied and pasted from another form. Simplest solution is to select the component, cut it, then paste it back. When you save, the component's unit will be added to the source, and when you run it again it will all be okay.
Well, a dfm file could be binary or tekst (as I'm correct from version 4.0).
You can check this by right click on the form and check the Text DFM flag.
If a dfm file is corrupt, tou can try to fix it by removing all suspicious lines.
Be sure to leave the object .. end sets intact and you probably only loose some property values.
By the way, the dfm file should look like this (to get an idea of the general structure):
object Form5: TForm5
Left = 0
DesignSize = (
426
652)
object Button1: TButton
Left = 343
end
object Memo2: TMemo
Anchors = [akLeft, akTop, akRight, akBottom]
end
end
If it does not look like that you are probably editing the binary file.
If you have a recent compiled exe that works, you can use a resource-editor, like PE Explorer, to get the dfm-definition. Then you can compare the one from the exe with the one that you now have.
I believe there is tools to convert binary dfm-files to text-files too. This will give you a better view on the file, and help you decide if it's really corrupted or not. I see Felix has something on the topic.
If the Delphi IDE shows the form ok without errors, I can't believe there is a corruption-error. Could there be a package problem? Do you use runtime-packages?
Update:
Hvae you tried Eurekalog or madExcept or something similar to get a more detailed error message with callstack and memorydumt? Maybe that will give you some clue about the problem.
But generally i think this error comes from missing runtime package, or a missing unit in the uses-clause. If you think you know witch component causes the error, search the source for the call to RegisterClass( ), and see if that unit somehow is included in the projcets uses-clause. If not, add it and try again.
If you can load the form in the Delphi IDE the DFM resource is not corrupted. Delphi uses the same code to load the DFM as the final executable will use, so I think that won't be the reason.
You can open the DFM in the Delphi IDE directly (if the corresponding pas file is not open), or you can use Alt+F12 to switch between form view and text view of the DFM. In this view the structure should be sane, with correct indentation and so on.
As Gamecat pointed out you can use the command in the form popup menu to toggle the DFM storage format. Leave it as text for Delphi 5+, it works better this way with SVN.
As for the cause of your runtime problem - I have no idea...
Edit: After your ruling out the DFM as the source of the problem I can only assume that an important unit in the uses list is missing, which can only happen if not all the components on your form have a corresponding member field. You should check that all the components referenced in the DFM are also in the form, even when you do not access them in your code. This will in turn cause Delphi to add any missing units to the uses clause when the file is saved. Manually registering components should not be necessary if the form class has references to all the components in the DFM.
For a quick check you could create a test form, drop all of the components that your "problem" form has onto it (one instance is enough), and check whether this works.
This can happen in case you have changed one of your custom components and removed a property from it. The property is stil in the DFM and Delphi tries to initialize it.
Try to remove manually parts from your DFM so you can pinpoint which component is causing the problem.
Try this:
Make backup first
Right click on form in designer; uncheck "Text DFM"
Save
Right click on form in designer; check "Text DFM"
Save