Dimensional Data

Last time, we looked at many possible customizations for Tabulator and other parts of a TMS WEB Core Project that were generally focused on the “look” of the application.  This included a handful of customizations to the content and format of the tables, as well as to other elements like images, fonts, and buttons.  The overall theme was changed a few times, resulting in the styling we have now, with a handful of CSS customizations to tweak every little detail.  This time out, we’re going to dig a bit deeper into the “feel” of the application.  Interacting with various elements, particularly with Tabulator, breathing a little more life into the application. Motivation. While there are many JavaScript grids available that work great within TMS WEB Core projects, and even when considering elements beyond grids and projects beyond TMS WEB Core, there are aesthetic properties (what we can see) but also interactive properties (what we can do) of the elements we select, as developers.  The aesthetic properties are perhaps easier to see and adjust, and in the TMS WEB Core project we’ve been creating, now called Actorious, we’ve seen how easy it is to use CSS to override the appearance of very nearly anything we want, from scrollbars to cell padding to fonts to borders.  Customizing interactions for a particular element is potentially more difficult, however, and we’re generally more reliant on an element’s built-in capabilities to help us out. But a web application has enormous potential for customizations even in this area.  We can add functionality and change element behaviors at will, with the goal of making the user experience as enjoyable as possible.  So in this post, we’re going to explore a bunch of these kinds of enhancements, while striving for a certain level of consistency and performance, filing off some rough edges along the way. Tooltips. Let’s ease into this topic with something that seems simple enough.  Tooltips.  In Delphi, they’re called hints.  And they work the same way straight out of the box in a TMS WEB Core application.  Add a button to a form. Add something to the Hint property. Hovering your mouse over the button produces a tooltip. We’re done, right?  Well, if you’ve been following along, you must know by now that we’re certainly not done at all.  We’ve not even really started! When it comes to tooltips generally, there are quite a few things you can customize to make them more useful or, alternatively, to get them out of your way.  The properties we’re going to address here are the overall look of the tooltip, the placement (relative to what it is linked to), as well as the delay – how quickly a tooltip appears and disappears.  For some tooltips, we actually want them to be almost instant.  And for others, we’d rather not see them at all most of the time.  Also keep in mind that tooltips might have varying levels of usefulness under different conditions.  Having a tooltip that shows “Biography” when you have a button that is clearly labeled “Biography” probably doesn’t make much sense, initially.  But later, when that row of buttons shrinks to just an icon if the form is displayed on a narrower display, suddenly the tooltip might be more useful. The look of a tooltip is […]

In this third stop on our Tabulator adventure, we’re going to focus mostly on the options available for how data is displayed.  But in order to help narrow our focus a little further, we’re going to take the TMS WEB Core project from last time, what we were calling ActorInfo, and explore ways we can view the data we have available, covering many Tabulator options along the way.  Styling and theming a modern web application potentially involves some amount of CSS work, so we’ll cover a bit of that as well.  And to keep it interesting for those not all that keen on Tabulator specifically, we’ll also cover how such a TMS WEB Core app might be deployed in a production setting. Motivation. As we discussed in the first of these Tabulator posts, having a grid control that does what you want, as a developer, makes for an enormously powerful tool. And for web applications, what developers are often after is the ability to customize, as much as possible, anything that is visible to the user.  This may arise from a need for a responsive interface that is accessible to everyone on every device. Or it may come from a desire to apply a specific style or theme, including color, logos, iconography, and that sort of thing.  Or some level of customization may be needed to address certain mechanical aspects of the interface or the underlying data.  Or it can be any combination of these, or other considerations entirely.  Point being, more options for customization are generally better for the developer.  Better still if there are reasonable defaults to start with and a consistent approach to customization that is not overly difficult to implement. The approach I’m going to take here is perhaps a little less organized than I’d like but reflects more accurately how this has come together.  We’ll start with where we ended up last time, and then systematically make changes to implement whatever customization is desired, outlining the steps and the thought-process along the way.  By the time we’re done today, we’ll have a pretty functional app, deployed and ready for users. And while I don’t expect anyone to particularly agree with my styling or theming or layout choices, the main takeaway should be, as usual, that you’ve got options!    Starting Point Two Disclaimers.  Just a couple of things to point out before we get too immersed in our work here.  First, there countless ways a developer can choose to implement any particular bit of functionality. And the same developer, facing the same choices, in the same app, may even implement the same thing in different ways.  And there are some examples of that on display here.  Sometimes, this is because I learned something new and haven’t gone back and updated the original code.  Sometimes, it’s because I’m lazy and cut and paste code where it isn’t really important (code executed infrequently, say), but might spend more time on the same thing in another spot where it is more important (code executed frequently in a loop, for example).  So don’t be too harsh when looking at any of this code.  I’ve tried to clean up the worst examples, but I’m sure some are lingering still.  Case in point, in the XData application, in the service endpoint, […]

Last time out, we started our adventure into Tabulator, a JavaScript library that provides a grid-style control that you can use in your TMS WEB Core projects. This time out, we’re going to focus on just one aspect – getting data into Tabulator.  The material in this post may also be of interest generally, no matter the grid control you’re using, or even if you’re just looking to get data into your TMS WEB Core application generally.  We’re going to dip our toe into SPARQL, used to query the data behind Wikipedia.  We’ll also show how to quickly set up an XData server as a proxy, both for SPARQL and other remote data sources.  This should be fun! Motivation. Tabulator, and virtually every other JavaScript-based grid control, is expecting to get data in JSON format, where the various components involved along the way have differing levels of rigidity when it comes to the JSON format itself, unfortunately, as will see. Sometimes other formats are supported, like XML or CSV, but JSON is almost always the primary method. This isn’t much of a surprise, of course, as JavaScript and JSON are very closely related to one another. Many interesting remote sources of data can be accessed via a REST API, and will often also, if you ask politely, return data in a JSON format.  All good.  However, formulating requests acceptable to the remote server, and being able to actually get the bits of data out of the JSON that you get back, can sometimes be adventures all their own. And at the same time, there may be issues in terms of how much data you can request from a remote API or how fast it can serve up the data you are interested in.  You might also be required to use an API key to make requests that you absolutely do not want to include in your TMS WEB Core application (or any JavaScript client application). And if you’re accessing multiple remote data sources, you might be multiplying the potential headaches to come. So in this post, we’re going to contact multiple remote data sources. We’re going to use a private API key. And we’re going to address performance aspects of the data we’re using.  Along the way, we’ll also be looking to explore a broader array of data types (images, for example).  And once we finally get hold of some data, we’ll add it to a Tabulator table.  We’ll also see if we can add a few nice finishing touches along the way, to help balance some of the Tabulator content in other upcoming posts. The example we’re going to develop here is a simple one, at least to visualize.  We want to use a date picker to select a birthday.  With that birthday, we want to see a list of all of the actors (movies and TV shows) that share that birthday.  And if we select an actor, we want to see all the movies and TV shows where they had a role.  Sounds easy enough right?  Well, the challenges here are not with TMS WEB Core or with Tabulator, but rather with the complexities of getting data from remote data sources.  But these are all solvable problems.  Just maybe a little more tenacity is required. Be warned, odd […]

So far, we’ve covered some hugely important and popular JavaScript libraries, like jQuery, Bootstrap and FontAwesome.  We’ve also explored other very important but somewhat lesser-known JavaScript libraries, like Luxon and CodeMirror.  And also some considerably smaller and less widely used JavaScript libraries like Interact.js, BigText.js and Showdown.js. Today we’re going to introduce what has quickly become my favorite JavaScript library, Tabulator, which accurately describes itself as “Easy to use, simple to code, fully featured, interactive JavaScript tables.”  Over the next handful of posts we’ll go into far more detail about how to make the most of it in your TMS WEB Core projects. Why Tabulator? Tabulator is neither wildly popular (yet!) nor particularly obscure. And it has perhaps the misfortune of falling into a hugely popular category of JavaScript libraries – defined with terms like grids or tables. If you were to do a Google search for a new JavaScript grid control, you might run through 10 or 20 before Tabulator even comes up on the list. On the other hand, if you search for a JavaScript ‘data grid’ on GitHub, it might come up second or third. But as with any popular JavaScript library category, there are plenty of criteria you can use to filter out which ones might be the best candidates for your projects. When I’m looking for something, these are the kinds of things I typically consider. Price per user or per developer, licensing terms, and so on? Any development activity in the past year?  Does the developer respond to questions? Are there dependencies?  Like jQuery or other JavaScript environments like React or Angular. How good/complete is the documentation?  Is there plenty of example code available? Style vs. substance and needs vs. wants.  Does it just look pretty or is it actually useful? When the dust settles, you might well reach the same conclusion I have, and give Tabulator a try. But even if you find another control that is more suited to your needs, or perhaps you’re already quite happily using another control, there’s still a lot of interesting ground to cover (and some fun examples) when it comes to using any of these kinds of controls in a TMS WEB Core project.  Motivation. The need for a grid-like control in a modern web application is usually self-evident. Displaying data for the user to see in tabular form, along with maybe some options to filter or sort that data in ways that are easy and convenient, is either something you need in your project, or something you don’t. A better question for our purposes might be what the motivation is for a Delphi developer to use a new and potentially unfamiliar JS library.  Particularly when it comes to providing functionality that we might already have decades of experience with, using popular, reliable, capable, and easy-to-use Delphi VCL components of various flavors. Naturally, this need arises when moving to a different environment – the web – where our preferred set of controls may not be as readily available.  At the same time, this shift to the web also brings with it opportunities to change how these kinds of applications are developed, for better and for worse.    TDataSet vs. The Web. When we covered all those JSON examples (see Part 1 and Part 2), one of […]

With the release of the new TMS FNC Chart version 2.0, it is now possible to show beautiful graphs based on the cell data in a TMS FNC Grid. This requires the installation of the TMS FNC UI Pack next to TMS FNC Chart. TTMSFNCChartGridAdapter The files for the TTMSFNCChartGridAdapter are available in the directory, but due to the dependencies to the TMS FNC UI Pack, they are not added to the packages by default. If you want to use the component in design-time it will be necessary to add the four different TTMSFNCChartGridAdapter units (and the Reg, DE and RegDE) with the prefix to the respective framework packages. Setup You can quickly set up the environment necessary to start. You need a TTMSFNCChart, a TTMSFNCGrid and the TTMSFNCChartGridAdapter.Link the Adapter property of the TMSFNCChart to the TMSFNCChartGridAdapter.And set the source of the TMSFNCChartGridAdapter to the TMSFNCGrid. You can now already start making your graph. As the default behavior of the TMSFNCChartGridAdapter will try to create a new series for each column that has a value in the first line. If it finds a text value in the first row it will use the first column it encounters as the x-value text. TTMSFNCChartGridAdapterSeries If you are using a more uncommon positioning of your data or you want to use multi-point data, you can use the TMSFNCChartGridAdapterSeries. This collection contains items for the different series that should be drawn in the chart.For this you’ll need to set the AutoCreateSeries property of the TMSFNCChartAdapter to False and add a new series item.There you can set the columns to use from your TMSFNCGrid. Now we set some the data in the cells. And set the format type of the X-axis to vftDateTime so it tries to parse the cell to a TDateTime format. Because the adapter only triggers when a cell has been edited, we need to call the Synchronize procedure when changing cells in run-time. procedure TForm.FormCreate(Sender: TObject); begin TMSFNCGrid.Cells[1,0] := ‘Date’; TMSFNCGrid.Cells[2,0] := ‘Low’; TMSFNCGrid.Cells[3,0] := ‘High’; TMSFNCGrid.Cells[4,0] := ‘Open’; TMSFNCGrid.Cells[5,0] := ‘Close’; TMSFNCGrid.Cells[1,1] := ‘7/06/2022’; TMSFNCGrid.Cells[1,2] := ‘8/06/2022’; TMSFNCGrid.Cells[1,3] := ‘9/06/2022′; TMSFNCGrid.Cells[1,4] := ’10/06/2022′; TMSFNCGrid.Cells[1,5] := ’11/06/2022’; TMSFNCGrid.Cells[2,1] := ‘24.8’; TMSFNCGrid.Cells[2,2] := ‘23.8’; TMSFNCGrid.Cells[2,3] := ‘22.8’; TMSFNCGrid.Cells[2,4] := ‘21.8’; TMSFNCGrid.Cells[2,5] := ‘20.8’; TMSFNCGrid1.Cells[3,1] := ‘32.5’; TMSFNCGrid1.Cells[3,2] := ‘30.2’; TMSFNCGrid1.Cells[3,3] := ‘34.6’; TMSFNCGrid1.Cells[3,4] := ‘30.2’; TMSFNCGrid1.Cells[3,5] := ‘33.7’; TMSFNCGrid.Cells[4,1] := ‘27.3’; TMSFNCGrid.Cells[4,2] := ‘25.3’; TMSFNCGrid.Cells[4,3] := ‘28.0’; TMSFNCGrid.Cells[4,4] := ‘30.1’; TMSFNCGrid.Cells[4,5] := ‘30.0’; TMSFNCGrid.Cells[5,1] := ‘25.3’; TMSFNCGrid.Cells[5,2] := ‘28.1’; TMSFNCGrid.Cells[5,3] := ‘30.2’; TMSFNCGrid.Cells[5,4] := ‘30.2’; TMSFNCGrid.Cells[5,5] := ‘24.6’; TMSFNCChart.DefaultLoadOptions.XValuesFormatType := vftDateTime; TMSFNCChartGridAdapter.Synchronize; end; procedure TForm.TMSFNCChartGridAdapterSynchronized(Sender: TObject); begin TMSFNCChart.Series[0].ChartType := ctCandleStick; TMSFNCChart.Series[0].MinXOffsetPercentage := 10; TMSFNCChart.Series[0].MaxXOffsetPercentage := 10; end; Events to customize the data To make it possible to manipulate the grid data some more, we’ve added a couple of events so you can set the chart to your liking.I’ve changed the TTMSFNCChart to a TTMSFNCBarChart, but it’s also possible to set the chart type of the series in the Synchronized event. // Example data procedure TForm.FormCreate(Sender: TObject); begin TMSFNCGrid.Cells[1,0] := ‘Prod-Num’; TMSFNCGrid.Cells[2,0] := ‘Product’; TMSFNCGrid.Cells[3,0] := ‘Price’; TMSFNCGrid.Cells[4,0] := ‘Volume’; TMSFNCGrid.Cells[5,0] := ‘Color’; TMSFNCGrid.Cells[1,1] := ‘CA-J-123.45’; TMSFNCGrid.Cells[1,2] := ‘CA-S-155.78’; TMSFNCGrid.Cells[1,3] := ‘CA-S-267.36’; TMSFNCGrid.Cells[1,4] := ‘CA-D-102.10’; TMSFNCGrid.Cells[1,5] := ‘CA-S-403.48’; TMSFNCGrid.Cells[2,1] := ‘Jeans’; TMSFNCGrid.Cells[2,2] := ‘Shirts’; TMSFNCGrid.Cells[2,3] := ‘Sweaters’; TMSFNCGrid.Cells[2,4] := ‘Dresses’; TMSFNCGrid.Cells[2,5] := ‘Shoes’; TMSFNCGrid.Cells[3,1] := ‘48.99’; TMSFNCGrid.Cells[3,2] := ‘26.99’; TMSFNCGrid.Cells[3,3] := ‘34.99’; TMSFNCGrid.Cells[3,4] […]

With the latest update of TMS FNC WX Pack, we released the new TTMSFNCWXMathEditor component. This component let’s you easily display and edit math formulae. No code is required to get started. Simply drop it on the form and you’re ready to go.  Virtual Keyboards Not only can you directly type in the math formula you want, you can also use virtual keyboards which are available in the component. There are multiple keyboards available to use like one for functions or one to type symbols with. These keyboards are customizable. You can set a theme, which keyboards to display and even when to show the virtual keyboard (i.e. on focus, manual, off, auto). LaTeX You can also type LaTeX commands to render your formula. Currently, there are over 800 LaTeX commands supported. The editor even gives you a visual aid when starting to type some of the commands. You can use LaTeX directly in the editor or use the Math property to set a default value to be shown. You can also export the typed in formula in LaTeX or in several other formats like spoken or ASCIImath.  Video Watch this video to get you started with the TTMSFNCWXMathEditor.

As many might know, FPC announced support for anonymous methods some days ago. This was one of the last pieces missing for us to be able to port TMS FlexCel to Lazarus and FPC.  So we decided to give it a try, and after a couple of days fixing stuff, we could make it compile. It wasn’t simple, there were internal compiler errors, there is missing functionality that had to be rewritten, and we haven’t reached 100% of the code, but most is compiling. Of course, compiling it is one thing, but getting it to work is a different matter. When we tried, we couldn’t create a simple xls or xlsx file. After a couple more days, we could get first xlsx and then xls working. We needed to do some patching in fpc, and we needed to workaround  some other stuff, but that’s the point where we are at right now. All of FlexCel code is compiling. It works in simple cases, but we haven’t tried our test suite yet. You can see here a little video of Lazarus in a M1 mac (but running as intel under rosetta) of me creating a simple xlsx file. And now comes the big question. Would you like us to spend more time on it so we add Lazarus support, or do we stop it now and focus in FlexCel for Delphi and FlexCel .NET as usual?  While we now have simple apps working, we won’t launch “Lazarus support” unless we have all tests passing, and FlexCel tests are quite difficult to pass. I expect some extra weeks of work to make it all pass. At least for now, we would focus in supporting Windows, OSX and Linux. No plans for iOS or Android. Important: To release support for Lazarus, we will require using the Trunk release until the current trunk is promoted to stable. We would really be interested in your opinion. If you want to share it with us, please answer the poll below or let us know what you think in the comments.

Last time out, we had a good look at CodeMirror 5, a JavaScript text editor that, among many other things, can be used to edit native HTML. This time out, we’re going to tackle the general topic of editing HTML in TMS WEB Core projects using two very similar JS libraries that both provide a WYSIWYG HTML editing interface – Summernote and SunEditor. And if neither of those are to your liking, there’s also a section at the end about how to convert Markdown text into HTML, using Showdown. Three different ways to tackle the same problem. Motivation Why might you need a WYSIWYG HTML editor in the first place? There are at least a handful of places I can think of where it might (or has) come up in TMS WEB Core projects. RichEditor. As a replacement for any needs that have historically been addressed using typical Windows RichEdit controls. Places where you want users to enter information, but you also want them to be able to use different text colors, bold or italic text, lists, tables, images, links, and so on. While such RichEdit controls have included support for some or all of these kinds of features, a WYSIWYG HTML control can typically do all of this and more, and usually you’re turning off things rather than trying to add editing functionality. Forums. If you have an area within your project where users can discuss things, like in a forum-type environment, this is sometimes a useful thing to have.  Markdown is also popular for this kind of thing, and is used to varying degrees in the TMS Support Center and on GitHub, keeping the UI as simple as possible. Documentation. For example, on a settings form, there might be a header at the top that describes some aspects about the settings that are specific to a client.  This description is stored as an HTML object in the client’s database and is displayed, if available, instead of the description that might be used by default. Naturally, access to editing these descriptions would be restricted to appropriate people. Or even if it isn’t customer-specific, sometimes storing the documentation in a database like this makes it possible to update the documentation that might be static within the application, but without having to release a new code update to make changes. Landing Pages. Customized web pages that cater to particular customers or marketing events or advertising campaigns.  These are just web pages that you track to see how much traffic is being generated by a particular campaign.  Or maybe you use them to A/B test what gets more conversions for a particular product.  Or something like that.  By being able to edit HTML directly within the application, these pages can all be managed from within your application – no need to worry about file access or server configurations or anything like that. Other Content. Sometimes applications have a ‘news feed’ or an ‘about’ page or a ‘contact us page’ or maybe corporate profiles, that kind of thing. Having a built-in HTML editor makes it easy to keep this kind of content up-to-date and also secured in a way that would likely be more difficult if people were editing HTML files in some other application and then uploading them to your server, for […]

Do you want to display or edit code directly within your TMS WEB Core application? Then this is the post for you.  This time out, we’re diving head-first into CodeMirror 5, which describes itself as “a versatile text editor implemented in JavaScript for the browser.”  Which it certainly is.  Beyond just being a text editor, it is natively aware of more than 100 different programming languages.  Beyond that, it has numerous add-ons and configurable options to mimic the many styles and conventions of other editors you might already be familiar with, like Vim, Emacs, and so on. And using it in a TMS WEB Core project is just as easy as any of the other JS libraries we’ve covered so far. Motivation. Why do we need a code editor at all? The very first benefit of a code editor, as compared to a simple text editor or an editable TWebMemo field, for example, is that it typically comes with syntax-highlighting that is configured for the programming language that you’re editing. For Pascal, this means that begin and end are automatically shown in a different color, as well as any other Pascal-related reserved keywords.  This also typically means that the various kinds of brackets are shown in a way that makes it easy to find the matching pairs of brackets, or that comments show up in a different color or style.  Might not seem like much, but if you’ve ever tried writing code without this, it is a very different experience. Of course, you’re likely very familiar with this kind of thing, as the Delphi IDE does exactly this (and much, much more!) when editing code.   Sometimes it is even helpful to display other text using this kind of mechanism, if for no reason other than to make it a little nicer to look at.  If you have log files that are potentially visible to your users, for example, they can be setup so that they are viewed through CodeMirror.  Perhaps set to something like SQL (my personal preference) will make the log files a little easier to read, depending on how they’ve been formatted, with dates and numbers and other things displayed potentially in a different color.  Or perhaps you want to display text that has line numbers beside it.  Or perhaps the most common of all, you want to edit HTML source and have the tags shown in a different color.  We’ll be taking a look at both Summernote and SunEditor in an upcoming post, both of which use CodeMirror to provide their “edit HTML source” functionality. CodeMirror 5 vs. CodeMirror 6. Before we get any further, let’s quickly sort this out.  Normally I’m 100% all-in when it comes to using the leading (bleeding) edge of any particular JS Library, with the thought that it will likely have the best support for the latest browsers and the most active development efforts, as compared to older versions of the same library.  And this does indeed apply here as well.  However, they’re a little too far out on the leading edge at the moment.  So far out that CodeMirror 6 is really a collection of modules that cannot be directly (perhaps easily would be more accurate) loaded into a web application, as we’ve been doing.  Instead, the various modules and their […]

Hello world!  You might have been used to see and read Stephanie in past posts, but today it’s time to introduce a new face! I’m Emmanuel, the internship Marketing and communication since 25th of January. My goal in this internship is to learn about the marketing side of development world, as well as creating video-, photo- and audio content for social media channels. In this blogpost we will discuss a new application that Stephanie created as internship project. The app in question is a navigation system that is based on FNC components. Before going further into it, I would like to discuss my journey within the development world as a Marketing student. It is quite important to know that I have little to no experience with coding, and that most of the components and code languages discussed in this video are mostly unknown to me. Which means that the experiences and point of view expressed could be different and less educated than most. My point of view, in some situations, is handful for having a full user perspective on the software that is being created. Sometimes a developer can create or design tools that might seem easy to them but isn’t really for the regular customer. It happens sometimes that I’m a first tester of a software that Stephanie creates. I, for example, helped her with the French language for the navigation software, as I am a native speaker. My first usage of the app also gave us path to new bugs, which were immediately patched. It feels good to know that even with no understanding of the coding world, one can still help in other ways.  My main task within the navigation app was to create a video for a quick demo of the finished application. There are a few steps to get done before starting with the video editing, which are: Introduction and learning of the software functionalities Agreement on what should be demoed Shooting and creating content + directing the present persons And afterwards starts the video-editing part, which isn’t a walk in the park! In the video, that was created in iMovie, you can also hear and see me for the French tutorial. Emmanuel Dernoncourt, Intern Marketing