Leaderboard

Hi All, Just a quick ping that an update to the Sempare Template Engine is now available... v1.7.7 It is also available on GetIt. Please star the project if you havn't already. (Thanks) Also for those watching Delphi Dev Days (https://www.codegear.com/DevDaysofSummer/) ... There will be a video posted today (15 Aug) with some demos showing some features and how easily the template engine can be included into projects... https://github.com/sempare/sempare-delphi-template-engine Changes: - fixed a few things - new 'functional includes' syntatic sugar - release mode builds will fail if the license confirmation is not acknowledged - also fully CI enabled now on github ... what is a functional include... Lets say we have a main template where we are creating an html form: <form method=post action=/register> Name: <input name=name> E-mail: <input name=email> <input type=submit value=register> </form> so what we could do from a templating perspective: <% template 'input' %> <% label %>: <input name=<% name %>> <% end %> <% template 'button' %> <% label %>: <input type=<% type %>> <% end %> <form method=post action=/register> <% input { label="Name", name="name" } %> <% input { label="E-mail", name="email" } %> <% button { label="register", type="submit" } %> </form> So above, you can see that we can have 'inline templates' that are named 'input' and 'button'. In the form section, the 'functional include' syntax is then used to pass the params... The alternative way of doing the include traditionally is a bit more verbose, but essentially the same: <form method=post action=/register> <% include 'input', { "label": "Name", "name": "name" } %> <% include 'input', { "label": "E-mail", "name": "email" } %> <% include 'button', { "label": "register", "type": "submit" } %> </form> The above is a bit more verbose, passing a dictionary, whereas the 'functional include' syntax can be a bit more pretty on the eye... So the nice thing then is that the inline templates could be moved out to separate files. The template registry can then be configured to load the various templates as required - from disk, resources, db, etc... Custom styling, etc can then be localised to the specific 'atomic' template. This works quite nicely when using stuff like TailwindCSS (https://tailwindcss.com/) , which lends itself to styles being inline rather than being in CSS files... Anyways, have fun. Please support me if you can.

To answer your question - you can't "return to the constructor" once it has exited. You would have to destroy the Form and recreate it. Maybe put the 'case' block inside a loop, and then exit the loop when you are done looking at tables? Hard to say since you did not explain what TChangesLogForm is actually doing and what exactly its relationship to JSDialog1 is. That being said, why is this dialog code in the Form's constructor? This does not look like good UI class design. This kind of logic should probably not be in the Form's constructor, but rather should be invoked in the calling code before the Form is created to begin with. Again, hard to say for sure without knowing more about your design.

Did the tone of this conversation lean towards mockery or belittling the person asking the question, or am I mistaken? You are mistaken. I've been coding for 43 years and I don't read assembler. I know what a *few* x86 instructions do. But not enough to look at a disassembled function and determine what the code does. At least, not without spending a LOT of time trying to figure it out.

Assembler of that code will show the truth... but I think that someone that ask such things do not have ability to read assembler. Disassembled code would reveal the code generated by the compiler. But it isn't going to reveal the contents of memory (registers, stack, or heap) prior to the code even executing. As Dalija points out, I could execute it once and the memory was zero at the time and execute it a thousand more times and the memory has values aside from zero.