FW Preview user style

[Marc Venken]

I highly recommend NOT modifying the FW source.

I recommend creating a new class that inherits from the FW class and create a method (with the same name) in that new class that contains the modification needed. This way when a new FW version comes out you won't have to keep modifying the source, you just inherit from the new source and override that one method.

Of course, if that method in the original source is modified in a new version of FW, then you will have to update your new class's method.

This is a standard OOP programming technique. It saves a lot of confusion and extra programming.

I also never want to change the originale code, so that i keep up with all new versions.
Calling a customised function like mr. Rao does is also very nice, but can it be done for every class ?

But the inherits stuff... That's interesting and not into my skills at this time...

James, or someone... Could you do the folowing ?

We have Xbrowse and I want to inherit with a function to customise it.

In the upperleft of xbrowse there should come a Icon with a customisation wheel to click, a menu should apear and 2 options to start with

1. Save Xbrowse settings
2. Load Xbrowse settings

[Otto]

Hello Marc,

>But the inherits stuff... That's interesting and not into my skills at this time...

That's exactly what I mean.

You have a wonderful idea but it's too complicated to implement.

There are very few developers working on the xBrowse development itself.

If you would outsource some functions (#include) then you could easily change things yourself and use your own includes.

Can you please post a screenshot.

#include is a power feature of Harbour.
Things that are often solved with code blocks could be solved in advance with different #includes.

Best regards,
Otto

[James Bott]

Here is a simple example of overriding a method in a class with a new class that inherits from the parent class.

Code: Select all  Expand view

/*
Purpose  : Simple example showing inheritance and overriding
           a method from the parent class
Program  : Inheritance.prg
Author   : James Bott, jbott@compuserve.com
Date     : 05/12/2022
Company  : Intellitech
Language : Fivewin/xHarbour
Updated  :
Notes    :

*/

#include "fivewin.ch"

Function Main()
   Local oDog, oHorse
   
   oDog:= TDog():New()
   oDog:Hello()
   
   oHorse:= THorse():New()
   oHorse:Hello()
   
Return nil

//------------------------------//

Class TDog
   Method New()
   Method Hello()
Endclass  

Method New() Class TDog
Return self

Method Hello() Class TDog
   msgInfo("Hello, I am a dog")
Return nil

//------------------------------//

Class THorse From TDog
   Method Hello()
Endclass

// Override Method Hello() from parent class
Method Hello() Class THorse
   MsgInfo("Hello, I am a horse")
Return self

// End

[Otto]

Dear James, thank you.

But it increases the complexity even more.

Please don't assume anything about yourself.

Think of programmers who take Fivewin just like that.
Here, for one thing, it would be important to have the source code of classes split across several files.
For example, the menu of the preview class in a separate file.

Changes would then be possible for every user.

Best regards,
Otto

[James Bott]

Otto,

>But it increases the complexity even more.

Why? You want to change the source code which is even more complicated. This means you have to start with a new copy of the original source code AND you have to upgrade it each time a new version of the FW software comes out. My example has both the parent class and the subclass in the same file. This was just for simplicity.

Normally, the FW classes are already compiled. You would just build a subclass to change the parent class. When a new version of FW comes out you just compile your subclass program the same as always.

Buy subclassing you don't have to do anything unless there was a change in the original method in that class. This should still be simple.

>Please don't assume anything about yourself.

I don't understand what you mean.

>Think of programmers who take Fivewin just like that.
>Here, for one thing, it would be important to have the source code of classes split across several files.
>For example, the menu of the preview class in a separate file.

You can't split a class into multiple files--it all must be in the same file. Subclassing can be in a separate file. This is one of the main features of OOP.

>Changes would then be possible for every user.

Hmm, instead of "user" I assume you meant "programmer." When using a subclass any programmer can change it without affecting the original class source code. And most times when a new version of FW comes out the subclass will not be affected. Simple.

[Otto]

Dear James,

thank you.
Nevertheless, I have this image in my head.


Best regards,
Otto

[Otto]

https://www.quora.com/Is-OO-programming-dead-in-2022
Dear James,

It's interesting, - sure it's AI inside google - now I get this heading suggested.
And this is really I ask myself and would also like to ask you about TData for mod harbour.

Working with mod harbour on backend, I think OOP is not so useful.

I'm going a different way. I have programmed a patcher and preprocessor.

So, I can glue the source code together similar to code blocks and also some kind of OOP.

But everything is straightforward to understand.

Best regards,
Otto

I add an example:

Code: Select all  Expand view

REQUEST DBFCDX
REQUEST DBFFPT

function main()
    local hdata := {=>} 
    local hPost
    local hINI := {=>}
    local nRecno := 1
    local cLogBuffer  := ""
    local cText := ValToChar( AP_PostPairs() )
    local cBuffer := ""
    local cDataNew := ""
    local nPos := 0
    local I := 0
    local aHashkeysValues := {}
    local cPair,  hPairs := {=>}
    local nPosPair := 0
    local cKeyPair := ""
    local cValue := ""
    local cRecno := ""
    local cDBFFile := "data\Kasse.dbf"
    *----------------------------------------------------------
   
   
    cText := STRTRAN( cText ,'<br>&nbsp;&nbsp;', '' )
    nPos := AT( "objBuffer", cText )
    cDataNew := substr(   cText, 2,    nPos - 4  )  
    cDataNew := STRTRAN( cDataNew ,'&nbsp;', ' ' )
    cDataNew := STRTRAN( cDataNew ,',"objDataNew',  '&' + '"')
    cDataNew := STRTRAN( cDataNew ,'objDataNew', '' )
   
    for each cPair in hb_ATokens( cDataNew, "&" )
        if ( nPosPair :=  At( ":", cPair ) ) > 0
            cKeyPair := Left( cPair, nPosPair - 1 )
            cKeyPair := UPPER ( STRTRAN( cKeyPair ,'"', '' ) )
            cKeyPair := STRTRAN( cKeyPair ,'[', '' )
            cKeyPair := STRTRAN( cKeyPair ,']', '' )
            cValue := SubStr( cPair, nPosPair + 3  )
            cValue := TRIM( cValue )
            cValue := LEFT( cValue, len( cValue ) - 1 )
            hb_HSet( hPairs, cKeyPair, cValue )
        endif
    next
   
    hPairs["SETUPDATENDATEN"]  := STRTRAN(  hPairs["SETUPDATENDATEN"] ,"\\","\")
    hPairs["DBFFILE"]  := STRTRAN(  hPairs["DBFFILE"] ,"\\","\")
   
    cDBFFile := hPairs["SETUPDATENDATEN"]  + hPairs["DBFFILE"]
   
    hPost   := hPairs
    nRecno  := VAL(   hPost[ "ID" ] )
   
    USE ( cDBFFile   ) ALIAS "data" SHARED
    Goto nRecno
    dbRLock()
    dbDelete()
    dbUnlock()   
   
    hdata['array'] := {}
    hData["recno"] := nRecNo
    hData['success'] := 'true'
    hData['posted'] := 'Data deleted successfully'
   
    CLOSE
   
    AP_SetContentType( "application/json" )
   
    ?? hb_jsonEncode( hdata, .T. )  // T=pretty
   
return NIL

[James Bott]

Otto,

>USE ( cDBFFile ) ALIAS "data" SHARED

There are lots of issues with the above. You have to find an available alias, and you can't open the same DBF file more than once (using the same alias) at the same time. A database object handles everything in one line of code:

oCustomers:= TCustomers():New()

Using your way, if you try to use the same database in multiple routines you also have to save and restore the databases state (current Alias, Recno, filter, order, scope, etc.). These issues make your code way more complex than using objects.

Your example of deleting a customer when using objects would just be:

oCustomers:Delete(nCustNo)

Another issue with your delete code: Presumably you would need to delete all other data related to that customer, so you would also need to delete sales orders, invoices, past due notices, etc. When using objects this would all happen with the same one line of code. Deleting the customer and their sales orders, invoices, and past due notices would all happen with this line:

oCustomers:Delete(nCustNo)

Still only one line! Granted there is more code, but it is encapsulated in the Delete() method. OOP encapsulates the delete code into the Delete Method so the code to delete is only written and debugged once. Thus you don't have different ways of deleting scattered around in your code.

If multiple programmers are working on the same program, they don't have to write any code to delete a customer. They just call the Delete() method.

I have taken old code that was thousands of lines long and distilled it down to 1/10 of it's original size using OOP. Note that (generally) reading OOP code is like reading a collapsed outline, which is so much easier to read and understand.

Sorry Otto, but I don't see how your technique is more "straightforward" and easier to understand than OOP. I do think you have not fully grasped OOP. I know when I first started using OOP, it was probably close to six months before I got to my Ah, Ha moment. This was the moment when I finally had a good grasp of OOP, and of how much easier and more stable OOP code is than traditional coding.

[Otto]

Dear James,
what I wanted to say is in mod harbour you have a single separate prg file for a request. That's it.
The file does its task and is closed.
I think for this stateless access and not having direct connection between frontend and backend, you maybe have to change the way of programming.

As you know, I use TData for years and have also extended database classes to business classes.

But now with mod harbour I get the impression that it is easier to go back to functional programming on the harbour side.
Sure on client side with JS classes are everywhere.

I got a new Ah, Ha moment. All is much easier than with desktop.
For users, it is normal to make a request and wait for the answer. On desktop, you have to have always live data, and you do things simultaneously. Not with web application.

In any case if you want to delete a record you have to call a separate prg on the server - a prg like I posted.
In this prg I do not see place for objects.
And the prg is closed immediately after deleting the record.
Same for edit and create.
I am posting this here because I believe that we should start to deal with the stateless concept in Fivewin programmes as well.
Best regards,
Otto

[Otto]

Dear James,
the most important thing about these prg-files is the speed of execution and that only the data that is needed is returned to the server.
Therefore, it needs minimal prg files.

Best regards,
Otto