[XE7]

Can I do something like:

uses
  {$IFDEF FOR-VCL}
    Vcl.Forms;
  {$ENDIF}

  {$IFDEF FOR-FMX}
    FMX.Forms;
  {$ENDIF}

:
:

F := TForm.Create(nil);

with TLabel.Create(F) do
  Parent := F;

:
:

#########

I guess I really have two questions:

(1) Is it "ok" to create low-level, utility units like this - to be included in both VCL and FMX apps.

(2) Is there some compiler directive (or anything) that tells me whether the compile is for VCL or FMX? (Otherwise, I probably have to create them in my standard DEFINES.INC file).

Thanks!

Remy Lebeau (TeamB) wrote:

> Then you have not properly separated your UI logic from your business
> logic.   Don't use a "shared" Form at all.  I would suggest exposing
> some kind of callback/interface in the Bug unit(s) that they can call
> into when they are ready to do something with a finished
> string/record.  Then your VCL code can assign its own
> handler/implementation that displays the data in a VCL Form, and your
> FMX code can assign own its handler/implementation that displays the
> data in a FMX Form.

Exactly. The "callback" can simply be a number of events than can be
handled by any kind of object.


-- 
Rudy Velthuis        http://www.rvelthuis.de

"if you keep doing what you've always done, you'll keep getting
 what you've always gotten."
 -- Jim Rohn

Thanks, guys!!

Free wrote:

> Now I find (making the D6 --> XE7 leap) that I need a different "BugXxx 
unit"
> for VCL & FMX simply because of the VERY PLAIN form that they "share".

Then you have not properly separated your UI logic from your business logic. 
 Don't use a "shared" Form at all.  I would suggest exposing some kind of 
callback/interface in the Bug unit(s) that they can call into when they are 
ready to do something with a finished string/record.  Then your VCL code 
can assign its own handler/implementation that displays the data in a VCL 
Form, and your FMX code can assign own its handler/implementation that displays 
the data in a FMX Form.  This way, the two Forms can use different controls, 
layouts, etc, and your BugXxx unit(s) can remain neutral and not have to 
care about things like that.

> **SHOULD I BE** abstracting the "TextToSomeWindow" aspect of this?

Yes.

--
Remy Lebeau (TeamB)

> {quote:title=Free Dorfman wrote:}{quote}
> Linden [in particular --- but anybody...]
> 
> I hear what you're saying. But - PLEASE - help me understand...
> 
> [BTW, I just leaped from Delphi 6 (D6) all the way to XE7. Consider myself ("thru D6") an OOP expert.]
> 
> I have some very general - integral to my life - debugging code:
> --BugMsg
> --BugMsgFmt
> --BugSL
> --BugDataRecord
>   etc.
> 
> These calls result in text appearing within a (VERY PLAIN - RichEdit & 5 buttons) form.
> 
> I uses these A TON. Have been for FIFTEEN PLUS years.
> 
> Now I find (making the D6 --> XE7 leap) that I need a different "BugXxx unit" for VCL & FMX simply because of the VERY PLAIN form that they "share".
> 
> So... if I make the "leap" this way, forever I have two units, each with its own BugXxx routine. 
> 
> That's the crux of it.
> 
> **SHOULD I BE** abstracting the "TextToSomeWindow" aspect of this? Is that (more of a design [and I'm not all-that-expert-at-all] issue) the thing that I'm missing here (leaping to XE7 -- or, now, not leap-y at all, just bad design??) 
> **???**
> 
> Continuing thanks!
> 
> Edited by: Free Dorfman on Jan 1, 2015 10:10 PM

Simplest solution 2 separate units ... as you say these do not change so ... FMX doesn't have a RichText control ... 

If there is a lot of logic (which I doubt) you could farm that out to a VeiwModel unit and then have two UI forms which get their content from that VM unit

That said if you use this type of debugging in Mobile Apps = PAIN


BTW have a look at codesite ... all the work done already
--
Linden
"Mango" was Cool but "Wasabi" was Hotter but remember it's all in the "source"

Edited by: Linden ROTH on Jan 1, 2015 11:12 PM

Linden [in particular --- but anybody...]

I hear what you're saying. But - PLEASE - help me understand...

[BTW, I just leaped from Delphi 6 (D6) all the way to XE7. Consider myself ("thru D6") an OOP expert.]

I have some very general - integral to my life - debugging code:
--BugMsg
--BugMsgFmt
--BugSL
--BugDataRecord
  etc.

These calls result in text appearing within a (VERY PLAIN - RichEdit & 5 buttons) form.

I uses these A TON. Have been for FIFTEEN PLUS years.

Now I find (making the D6 --> XE7 leap) that I need a different "BugXxx unit" for VCL & FMX simply because of the VERY PLAIN form that they "share".

So... if I make the "leap" this way, forever I have two units, each with its own BugXxx routine. 

That's the crux of it.

**SHOULD I BE** abstracting the "TextToSomeWindow" aspect of this? Is that (more of a design [and I'm not all-that-expert-at-all] issue) the thing that I'm missing here (leaping to XE7 -- or, now, not leap-y at all, just bad design??) 
**???**

Continuing thanks!

Edited by: Free Dorfman on Jan 1, 2015 10:10 PM

> {quote:title=Free Dorfman wrote:}{quote}
> What about the idea of a BUILT-IN compiler directive...?
> 
> How will (can) my code know whether it's a VCL compile or an FMX compile?

Not that I know of .... but Y - it a lot of work to maintain 2 code bases but with the ifdef (even it you create one yourself) it will be a nightmare ... dealing with integer vs real for stuff like position - caption vs text etc

Controls that look similar have subtle differences keydown vs keypress

Plus the FMX version will work every where the VCL will - so keep your common code generic and you would need a compiler directive 

It IMHO not a practical idea 

--
Linden
"Mango" was Cool but "Wasabi" was Hotter but remember it's all in the "source"

What about the idea of a BUILT-IN compiler directive...?

How will (can) my code know whether it's a VCL compile or an FMX compile?

> {quote:title=Free Dorfman wrote:}{quote}
> [XE7]
> 
> Can I do something like:
> 
> uses
>   {$IFDEF FOR-VCL}
>     Vcl.Forms;
>   {$ENDIF}
> 
>   {$IFDEF FOR-FMX}
>     FMX.Forms;
>   {$ENDIF}
> 
> :
> :
> 
> F := TForm.Create(nil);
> 
> with TLabel.Create(F) do
>   Parent := F;
> 
> :
> :
> 
> #########
> 
> I guess I really have two questions:
> 
> (1) Is it "ok" to create low-level, utility units like this - to be included in both VCL and FMX apps.
> 
> (2) Is there some compiler directive (or anything) that tells me whether the compile is for VCL or FMX? (Otherwise, I probably have to create them in my standard DEFINES.INC file).
> 
> Thanks!


You can easily combine business logic units in both VCL and FMX however the idea of using the same unit for both VCL and FMX would be maddening ... so much is different so you'd have more IFDefs than real code

Just have 2 apps FMX and VCL. Then put all you logic in non UI units ... http://en.wikipedia.org/wiki/Model_View_ViewModel

--
Linden
"Mango" was Cool but "Wasabi" was Hotter but remember it's all in the "source"