In the VCL removing a TEdit’s background is no problem – set its ParentColor property to True, and its BorderStyle property to bsNone. Neither the Color, ParentColor not BorderStyle properties exist on the FMX TEdit however, since all these attributes are controlled by its style.

So, one’s first thought might be to create a custom style for the edit box. To do that, right click on the TEdit in the form designer, then choose Edit Custom Style… from the popup menu. Once the style editor is showing, head to the structure view, open up the control hierarchy, select the item labelled ‘background’, then click the little ‘delete’ button (top left). Choose ‘Apply and Close’, and both the edit box’s white background and its thin border should be gone. Great!

Alas, but there’s a problem – if you change the global style, the edit box’s custom style won’t be updated accordingly. E.g., here’s what happens when the ‘dark’ style is loaded:

The problem here is that custom styles set up at design time involve merely ‘copy and paste “inheritance”‘ from whatever style is used by the IDE at the time. Change the main style for an application later, and any custom style won’t have its underpinings updated accordingly.

While this inherent limitation of the FMX styling system is bad enough in the present scenario, it is even worse for things like customising a list box item’s style, since the default platform styles differ (as you might expect) on details like highlight colours – just try running XE3′s CustomListBox demo on OS X to see this in action. Another pain point is the XE3 platform styles relying on their own bitmaps, one per platform – since no care was taken for each control to refer to the same part of the main bitmap when running on Windows and OS X, customising a control’s style at design time can lead to half of it disappearing when the program is run on a Mac!

What we need to do, then, is not use a custom style, but correct the default style for a read-only edit box at runtime, specifically by manipulating things in a handler for the control’s OnApplyStyleLookup event. Learning what to modify exactly means delving into the source and the stock style files, preferably more than one in the case of the latter. To take the TEdit case, for example, while all the standard styles define its background by a control with a style element name of ‘background’, the control type depends upon the style. In the case of the ‘platform’ styles it is a TSubImage, which references part of one big platform-specific bitmap. In the case of the additional, vector-only styles however (like ‘dark’), a TRectangle is used. Given that, removing the background must be done in a way that is neutral between both primitive control types (i.e., TSubImage and TRectange). In fact, it’s a good idea to make the code as generic as possible, since it’s perfectly possible Embarcadero will change the internals once more in XE4 or whatever.

Anyhow, to cut to the chase, this is what I’ve come up with -

procedure TForm2.LabelEditApplyStyleLookup(Sender: TObject);
var
  Obj: TFmxObject;
begin
  Obj := (Sender as TCustomEdit).FindStyleResource('background');
  if Obj is TControl then TControl(Obj).Opacity := 0;
end;

Why make the background control transparent rather than just delete it? Ultimately, because I’m not keen on just randomly deleting internal objects. Further, talk of automatic reference counting (ARC) being introduced (see here) makes me nervous simple Free calls on FMX objects (*) will even be possible in the future given the inherent conflict between reference counting and the TComponent ownership pattern that FMX currently employs.

(*) And no, I’m not predicting ARC will be forced (or even introduced at all) for Win32/Win64 projects. I’m purely talking about FMX, on mobile and possibly desktop too given much of the framework will presumably cross compile between mobile and desktop platforms.

1. Add a TImage to the design surface.
2. Using the structure view (top left of the IDE), reparent the image to the desired button by dragging and dropping with the mouse. (It doesn’t matter whether the button is a TButton, which takes the keyboard focus, or a TSpeedButton which doesn’t.)
3. Select the image and use the object inspector to set its HitTest property to False. This prevents it from receiving mouse clicks.

This approach works fine if the button doesn’t have a caption, but when it does, an issue arises concerning alignment: the text will remain centred in the button regardless of whether the image is aligned to a certain side, so that if the image is relatively large, text will appear partly on it, and partly on the normal background:

If the button images are either left-aligned (as in this example) or right-aligned, you could manually fix up the alignment by prepending or appending spaces to the button’s Text property as appropriate, however this won’t work for top- or bottom-aligned images, and moreover, causes hassles if the button’s text comes from an assigned action. So, what would make for a more principled fix?

Well, internally, a button’s text is part of its style, which like the style for any other control is composed of more primitive FMX controls. The text, then, comes from a TText control, which is placed inside a layout control of some sort that also contains a TSubImage or TRectangle that defines the button background and border.

Given that, one way to fix the text alignment issue might be to reparent our TImage to the parent of the TText at runtime. If that sounds a bit hacky, that’s because it is, and worse, the changes made to control style handling in XE3 blogged about by Eugene Kryukov (EMBT) here make it precarious to boot. Happily however, there’s a better way: when the button’s style is loaded (or reloaded), adjust the internal TText’s Padding property so that it no longer overlaps the image.

To do this generically for a number of buttons on a form, select them all in the designer (they can be a mixture of TButton and TSpeedButton controls if you want), click to the Events tab of the Object Inspector, type ButtonApplyStyleLookup next to OnApplyStyleLookup, and press Enter. This will create a shared event handler for the buttons’ OnApplyStyleLookup event. In the code editor, add the following for its implementation:

procedure TForm1.ButtonApplyStyleLookup(Sender: TObject);
var
  Button: TCustomButton;
  Control: TControl;
  TextObj: TFmxObject;
begin
  Button := (Sender as TCustomButton);
  for Control in Button.Controls do
    if Control is TImage then
    begin
      TextObj := Button.FindStyleResource('text');
      if TextObj is TText then
        case Control.Align of
          TAlignLayout.alLeft:
            TText(TextObj).Padding.Left := Control.Width;
          TAlignLayout.alTop:
            TText(TextObj).Padding.Top := Control.Height;
          TAlignLayout.alRight:
            TText(TextObj).Padding.Right := Control.Width;
          TAlignLayout.alBottom:
            TText(TextObj).Padding.Bottom := Control.Height;
        end;
      Break;
    end;
end;

What we do here is cycle through the button’s controls looking for the TImage; when we find it, we then look for the TText style resource and adjust its Padding accordingly. Here’s the result:

PS – if having read this far you’d still prefer a button class with a dedicated Bitmap property, check out Mike Sutton’s custom TSpeedButton descendant here.

Then,  reality sets in.

You find out that a part you planned to purchase doesn’t exist in your size, a stress test shows the design needs to be more robust and a few ounces lighter, or the nose cone just kind of looks funny. You find yourself going back to your design again and again as the deadline nears.

But try to change anything quickly in the CAD system, and you may find the model tree fights you. Even trivial modifications can be a headache.

You’re not the first student with this problem. That’s why we introduced the PTC Creo Flexible Modeling Extension (FMX). In short, it frees you from the constraints of traditional parametric modeling, so that you can make changes quickly and get your finished entry to the track before your competition begins.

The clip below was made just for students like hypothetical you entering the SAE Collegiate Design Competitions (one of which is exactly the race car challenge I described above). The video shows how you can make those last-minute changes in PTC Creo Parametric by switching on FMX.

And one more thing. When I said you’re the reason we introduced FMX? That wasn’t exactly the whole picture. We did it for professional engineers everywhere. It may start in university, but we all accommodate late changes, some of them dramatic, all through our design process, all through our careers.

Welcome to our world.

PTC is very proud to support you and all of tomorrow’s engineers through STEM programs like the SAE Collegiate competitions.

Is just a promo video, but I’m super excited!

Enjoy the vid!

Having been bugging me for a while, I finally decided to investigate the problems properly. First up was the showing-twice issue. At first I thought it must be dialog-related, but it wasn’t:

• As in the VCL, the FMX TForm has CloseQuery and Close methods, with the implementation of the latter calling the former. (Unlike in the VCL, FMX does not abstract out calling the OnClose event into a DoClose method. Instead, it is called directly inside Close. But I digress)
• At the platform-specific level, FMX.Platform.pas calls CloseQuery in response to the windowShouldClose: message, which is good, and Close in response to windowWillClose:… which is bad. Why? Because as its name implies, by the time windowWillClose: is sent, the window is closing, not asking whether it should close. When the user clicks the red traffic light, the message order is therefore windowShouldClose:, and if that returns True, windowWillClose:. When OnCloseQuery has been handled without setting CanClose to False, this means it gets called a second time. Doh!
• Instead of calling Close, the windowWillClose: handler should just invoke any assigned OnClose handler, if that. If a DoClose method had existed, perhaps the author would have at least thought whether Close rather DoClose is really appropriate…

Now, I say that windowWillClose: should call OnClose ‘if that’ because OnClose itself acts as a ‘are you really, really sure you want the form to close?’ event. This is because if a handler sets the Action var parameter to TCloseAction.caNone, in principle, the form should not now close:

procedure TForm2.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  if MessageDlg('Are you SURE you want the form to close?',
    TMsgDlgType.mtConfirmation, mbYesNo) <> mrYes then
    Action := TCloseAction.caNone;
end;

Predictably enough though, such code doesn’t work when targeting OS X, assuming Close is called because of the user attempting to close the form rather than the form being closed programmatically. More exactly, setting Action to anything beyond the default (caHide) doesn’t have any affect, because Cocoa has already decided what will happen. To make even OnClose work correctly, then, almost the entire logic needs to be placed in the windowShouldClose: handler, and the windowWillClose: handler left relatively bare.

As for the bug of OnCloseQuery not being raised at all, the problem there is specific to a modal form being closed due to its ModalResult property being set, either directly or via a button. Looking at the source, the CloseModal call inside TPlatformCocoa.ShowWindowModal looked suspicious, and sure enough, it was the problem:

• As before, the FMX TForm mimics its VCL forebear in having a CloseModal method. In the VCL (and FMX/Windows), this is is called inside the modal message loop once a change in the form’s ModalResult property has been detected. CloseModal itself then calls CloseQuery to give the client code the chance to cancel the closure; if CloseQuery returns False, the ModalResult property is reset to mrNone (0). Back in the modal message loop, the ModalResult property is then checked a second time to allow any reset to take effect.
• The author of TPlatformCocoa.ShowWindowModal misunderstood the purpose of CloseModal, apparently assuming it is some sort of notification method rather than a ‘last chance to cancel’ one. As such, CloseModal is called in the wrong place (too late), and ModalResult not rechecked.

Here’s how to fix these various bugs:

• Take a copy of FMX.Platform.Mac.pas, and put it in your application’s main source directory (you can also explicitly add it to the project if you want).
• Open the copy and head to the TFMXWindow.windowShouldClose method implementation. Change it look like this:

function TFMXWindow.windowShouldClose(Sender: Pointer): Boolean;
var
  Action: TCloseAction;                                  //!!!CCR
begin
  Result := False;
  if Application = nil then
    Exit;
  if Application.Terminated then
    Exit;
  try
    Result := Wnd.CloseQuery;
    if Result and Assigned(Wnd.OnClose) then             //!!!CCR
    begin                                                //!!!CCR
      Action := TCloseAction.caHide;                     //!!!CCR
      Wnd.OnClose(Wnd, Action);                          //!!!CCR
      if Action = TCloseAction.caMinimize then           //!!!CCR
      begin                                              //!!!CCR
        Result := False;                                 //!!!CCR
        Wnd.WindowState := TWindowState.wsMinimized;     //!!!CCR
      end                                                //!!!CCR
      else                                               //!!!CCR
        if (Application <> nil) and                      //!!!CCR
           (Wnd = Application.MainForm) then             //!!!CCR
          Result := (Action in [TCloseAction.caHide,     //!!!CCR
            TCloseAction.caFree])                        //!!!CCR
        else                                             //!!!CCR
        begin                                            //!!!CCR
          Result := (Action = TCloseAction.caHide);      //!!!CCR
          if Action = TCloseAction.caFree then Wnd.Release;
        end;                                             //!!!CCR
    end;
  except
    Application.HandleException(Self);
  end;
end;

The next method down is probably TFMXWindow.windowWillClose; in it, delete everything, before adding the following in its place:

procedure TFMXWindow.windowWillClose(
  notification: NSNotification);
begin
  if (Application <> nil) and (Application.MainForm = Wnd) then
    Application.Terminate;
end;

The addition preserves the ‘main form’ semantics we implicitly remove by not calling Close (which would otherwise enforce them).

The revised windowShouldClose and windowWillClose methods fix the double shows and OnClose not working properly; to fix the no-shows, head next to the implementation of TPlatformCocoa.ShowWindowModal. Find the call the AForm.CloseModal, and comment it out (it’s in the wrong place). Finally, find the check for AForm.ModalResult not being 0, and amend the code to look like this:

          if AForm.ModalResult <> 0 then
          begin
            AForm.CloseModal;                     //!!!CCR
            if AForm.ModalResult <> 0 then        //!!!CCR
            begin                                 //!!!CCR
              NSApp.stopModal;
              Continue;
            end;                                  //!!!CCR
          end;

To take effect, you may need to disable debug DCUs to ensure the revised unit gets picked up (Project|Options, Delphi Compiler > Compiling, uncheck ‘Use debug DCUs’ – you’ll only need to do this for the OS X debug configuration).

As a final point, please keep in mind I do not encourage invoking event handlers directly, as the code above does – the fact the FMX source doesn’t bother with dedicated event-calling methods half the time says nothing about the validity of such practice. The only reason I do it above is because I wish to avoid interface changes, and therfore, DCU incompatibilities.

Thankfully, the delay didn’t last long. By about 7:00 they were open for business. Red Bull graciously gave us access to shoot from several amazing vantage points – nothing like the smell of 2-stroke fuel and a bit of mud on the knees! I’ll just let the pictures tell the story.

Nick De Wit and Fredrik Berggren talk before the show

Chris Fisher from Merge 104.8 interviewing the riders

I also had the chance briefly to make it over to the drifting exhibition (not a Red Bull event). If you’re not familiar with the sport, here is the definition from the Formula Drift Asia website:

Drifting is a high-skill, high-powered motorsport that calls for drivers to control a 200 to 600hp car while it slides sideways at high speed through a marked course. It is similar to rally racing, but is done on a closed course and judged on execution and style rather than who finishes the course fastest. Drifting takes all the thrilling moments of traditional motorsports and packs it together into non-stop competition.

These shots will give you an idea.

The crowd was enthusiastic and used lots of creative ways to get a view of the action.

The spookiest 

Sometimes you gotta climb to get your shwarma

I’m thankful to Red Bull for being gracious hosts. Lots of fun. For more coverage of the event, check out Andy in Oman’s blog. He’s posted some cool video including a clip from a Go Pro attached to the helmet of one of the riders.

Peace, love, and fumes.

“Hi Everyone

All in all then, the core functionality I required was implemented by the framework. However, by default, the behaviour wasn’t quite what I wanted:

• While making it no effort to have a list box item draggable outside its parent was great, I didn’t want the accompanying reordering visuals when the dragged item was still within the list box bounds.
• Most FMX controls visually indicate that they will accept an object being dragged over them regardless of any OnDragOver handler being set. So, if the form has a list box, a grid and a panel, and a list box item is being dragged, all three controls, together with the remaining list box items, will appear to accept the item as the item is dragged over it. (In the list box’s case, the entire list box is highlighted if you aren’t hovering over a specific item.)
• In the case of a grid, each column header will indicate acceptance individually as well. Worse, they also support dragging and dropping between themselves to reorder and dragging to somewhere outside the grid with no obvious way to turn either ability off! Speaking for myself, this means I find it pretty easy to reorder the columns of a FMX grid without intending to. Moreover, the fact you can drag a grid header outside the grid is just confusing:

In looking to fix these issues, the first thing I discovered was that the annoying visual acceptance effect is controlled by the EnableDragHighlight property, as introduced with public visibility (and a default setting of True!) in TControl, and subsequently published by most descendants. This property has zero connection to the OnDragOver event, which means that regardless of what you do in an OnDragOver handler, or indeed whether you have a handler for that event at all, by default, a control will visually indicate it accepts anything and everything being dragged over it. Nonetheless, if you have a number of controls that will never accept a dragged object, the easy fix is just to select them all at design time and toggle their EnableDragHighlight property to False. In my case that meant selecting everything on the form, deselecting the popup menus (which don’t have an EnableDragHighlight property), toggling the property in the Object Inspector, then individually putting the property back on a case-by-case basis.

This was also the fix for removing the reordering visuals from the list box, since TListBoxItem is one of the TControl descendants that publish EnableDragHighlight. In principle, you should still need to remove the actual reordering if an internal drag and drop happens accidentally. However, due to an oversight in the FMX source, the actual reordering doesn’t happen – the items are repositioned in the internal list of child objects, but their positions on screen are not switched similarly. Assuming that bug will one day be fixed though, the way to prevent any reordering is to handle the list box’s OnDragChange event and set the Allow parameter to False:

procedure TForm1.ListBox1DragChange(SourceItem,
  DestItem: TListBoxItem; var Allow: Boolean);
begin
  Allow := False;
end;

So, that left the grid headers… oh, and the listbox itself, since while setting EnableDragHighlight to False in the Object Inspector worked for individual list box items, it stubbornly wasn’t for their parent control:

Looking at the source, the reason stemmed from the AutoDrag property setter forceably setting EnableDragHighlight to True. Why? Who knows, but anyhow, where EnableDragHighlight is published by an ancestor class, TScrollBox, AllowDrag is published by TCustomListBox. Ergo, the persisted value of AllowDrag will be read back in after the persisted value of EnableDragHighlight, causing the former to override the latter. The fix is therefore to set the list box’s EnableDragHighlight property to False at runtime in (say) the form’s OnCreate handler:

procedure TForm1.FormCreate(Sender: TObject);
begin
  ListBox1.EnableDragHighlight := False;
end;

This just left getting rid of the grid column headers’ default draggability. Since a FMX grid’s header is defined by its style, the place to tweak the settings of it is in a handler for the grid’s OnApplyStyleLookup event. In terms of what needed to be done there, initially I thought of EnableDragHighlight again, but that wouldn’t solve the problem of the header items being themselves draggable. I then realised that the columns themselves were child controls of the grid just as much as the header, and they didn’t have independent draggability (so to speak). The reason for that, it became clear, was because their HitTest properties are set to False by the grid. So, the fix for the header was just to set both the header and its own child control’s HitTest properties to False likewise:

procedure TForm1.Grid1ApplyStyleLookup(Sender: TObject);
var
  StyleObj: TFmxObject;
  ChildObj: TControl;
begin
  StyleObj := (Sender as TCustomGrid).FindStyleResource('header');
  if StyleObj is THeader then
  begin
    THeader(StyleObj).HitTest := False;
    for ChildObj in THeader(StyleObj).Controls do
      ChildObj.HitTest := False;
  end;
end;

This of course means the user cannot click on a header item. If you want to have that, assign the header items’ OnClick handlers as desired, set their DragMode properties to TDragMode.dmManual, and their EnableDragHighlight properties to False:

procedure TForm1.Grid1ApplyStyleLookup(Sender: TObject);
var
  StyleObj: TFmxObject;
  ChildObj: TControl;
begin
  StyleObj := (Sender as TCustomGrid).FindStyleResource('header');
  if StyleObj is THeader then
  begin
    THeader(StyleObj).HitTest := False;
    for ChildObj in THeader(StyleObj).Controls do
    begin
      ChildObj.DragMode := TDragMode.dmManual;
      ChildObj.EnableDragHighlight := False;
      if ChildObj is THeaderItem then
        THeaderItem(ChildObj).OnClick := MyHeaderItemClick;
    end;
  end;
end;

(As an aside, you will frequently find the FMX source doing an Assigned check before using the ‘is’ operator – if the above code were written by an FMX author or maintainer, you would therefore expect to see ‘if Assigned(StyleObj) and (StyleObj is THeader) then’ rather than just ‘if StyleObj is THeader then’. This is completely unnecessary however, since the ‘is’ operator checks for nil itself.)

We talked about how PTC Creo Flexible Modeling Extension can lead to less duplication, better preservation of design intent, and a flatter learning curve as you make the most of both parametric and direct modeling for your project.

Use the PTC Creo Flexible Modeling Extension when you want to:

1. Explore more ideas during concept design.
2. Drive late-stage design changes.
3. Re-use legacy 3D design data.
4. Collaborate on a multi-CAD design.
5. Improve CAE & FEA workflow.
6. Improve manufacturing workflow.

Part 1 of this article explored the first three of these use cases. Here is how you might use the PTC Creo Flexible Modeling Extension for collaboration, CAE & FEA workflow, and manufacturing workflow:

4. Collaborate on a Multi-CAD Design

The study “Working with Multi-CAD? Overcome the Engineering Collaboration Bottleneck” found that 82% of best-in-class product development firms use three or more CAD formats in their design process, and 42% use five or more.  Why? 52% report that supply chain/partners or customers used a variety of CAD tools, and 45% say they need all those CAD tools to deal with legacy data used for new designs.

Design collaboration on multi-CAD data presents two substantial challenges. CAD tools are often incompatible, and 3rd party CAD models are difficult to modify and incorporate when imported. If a model can’t be imported, it needs to be recreated — a painful and time-consuming process.

With the PTC Creo Flexible Modeling Extension, users can use 3rd party CAD files, regardless of source. Now you can add parametric design intent to imported data, so you can easily incorporate and edit CAD data from other systems.

See how PTC Creo supports the fast and easy collaboration on multi-CAD data, so that you don’t have to worry about original design intent:

5. Improve CAE & FEA Workflow

Product development demands frequent analysis of the digital prototype as the design evolves. Often, the digital prototype is simplified and de-featured for analysis. With the Creo Flexible Modeling Extension, anyone on the team can remove blends, small holes, faces, features, and other irrelevant geometry. You can even chop off geometry unrelated to the simulation or split models according to symmetry.

PTC Creo can automate simplification and de-featuring work, saving time and repetition during the analysis cycle so teams can freely and frequently update and validate designs with no redundant effort. With PTC Creo, you have the tools to prepare models for analysis without relying on the design engineer, and without requiring a parametric CAD expert. Easily simplify geometry like chamfers and rounds using direct modeling. Then you can run an analysis on the model with these design changes in any simulation environment, or seamlessly into PTC Creo Simulate.

6.  Improve Manufacturing Workflow

Obviously, manufacturing the design is important. Yet, often, the fully detailed model doesn’t reflect the different manufacturing representations required for production machining.  For example, the first stage of manufacturing the product may be the purchase of a blank part – such as a piece of metal used to form or machine further mechanical operations. Manufacturing engineers may well want to reflect the part through key stages like milling or drilling.

PTC Creo can automate this work, saving time and repetition during the manufacturing stage. With Creo, you have the tools to create a blank by removing features- without relying on specialists to do the work. Easily remove geometry like holes, or raise machined surfaces to create the blank or manufactured stage. Then you can easily create a manufacturing routine with these design changes in any manufacturing environment or seamlessly with PTC Creo manufacturing software.

If you’d like to see what PTC Creo Parametric can do for you, try it free. Just download the 30-day trial.