Rich Edit Text Object Model project

[José Roca]

If you bother to read the documentation of my WinFBX framework, you will seee that I offer all that PowerBasic offers and much more, and my CWindow class is better than DDT and as easy to use, and it has the advantage that is 100% SDK compatible.

See: https://github.com/JoseRoca/WinFBX/blob/master/docs/Windows%20GUI/CWindow%20Class.md

I also write extensive documentation and provide many examples. I consider that good documentation is essential, even if it takes me more time that to write the code.

An editor as complex as WinFBE (by Paul Squires) has been written entirely using my framework. This is a proof of how powerful it is.

And if I die, I'm providing the source code.

And if nobody uses it, I don't care. I'm working on it to keep my mind in good shape.

[José Roca]

I was very disappointed when Bob incorporated a graphic control that could only work with DDT. Also, because it was a subclassed image static control, it could not deal with alpha blended images. Therefore, I made my own graphic control that not only supported alpha blended images, but also has support for GDI, GDI+ and OpenGL, whereas the PB Graphic control only has native support for GDI.

Classes work so well in FreeBasic, that I'm thinking in writing several more that will incorporate related procedures of my framework.

For example, a CString class, with these methods (other that the intrinsic ones already provided by the language):

ClipLeft
ClipMid
ClipRight
Cset
Delete
Extract
Insert
Join
LCase
LSet
Parse
ParseCount
Remain
Remove
Repeat
Replace
Retain
Reverse
RSet
Shrink
Split
Spn
Tally
UCase
UnWrap
Verify
Wrap

and some more specialized such

Base64Decore
Base64Encode
CryotBinarytoString
CryptStringToBinary
etc.

[Johan Klassen]

very interesting José

[José Roca]

I have added methods and properties to get/set the text color, height, offset and font face name of the selected text or the worder under the cursor if there is no slection. I have also added properties to get/set the bold, italic, strikeout and underline attibutes. These are toggle properties, i.e. if the text or word is not already bolded, it bolds it, and viceversa. This is useful if you write an editor with buttons to set/unset them (you only need a button, instead of two, to do it). If you want to do it programatically, there are properties (IsTextBold, etc.) to check its state, e.g. If pRichEdit->IsTextBolded returns false, call the SetTextBold method to bold it, and if it returns true, do nothing.

To do it programatically, first select the text with the SetSel method.


Printing must not be too difficult because I already have working methods to get the text and also a print class (CPrint).
See: https://github.com/JoseRoca/WinFBX/blob/master/docs/Printing/CPrint%20Class.md

[José Roca]

With the FreeBasic classes I'm able not only of write wrappers and objects, but even implement new data types that can be used as if were native.

For example, FreeBasic has not yet a Unicode dynamic string, so I wrote CWSTR ( https://github.com/JoseRoca/WinFBX/blob/master/docs/String%20Management/CWSTR%20Class.md ). There were some quirks when I wrote it, but coderJeff was kind enough to modify the compiler to eliminate them and now it behaves as if it was a native data type, working directly with the intrinsic Free Basic string functions and operators.

So I like FreeBasic because it allows me to extend the language.

[Zlatko Vid]

Nice

So I like FreeBasic because it allows me to extend the language.

my observation to this will be ...

I like to use OxygenBasic because it allows me to use it in a way i want. 

[José Roca]

I'm glad you finally found a compiler you like. You've been wandering around every forum out there.

[Theo Gottwald]

𝐼'𝑚 𝑛𝑎𝑡𝑢𝑟𝑎𝑙𝑙𝑦 𝑑𝑖𝑠𝑎𝑝𝑝𝑜𝑖𝑛𝑡𝑒𝑑 𝑡𝘩𝑎𝑡 𝑦𝑜𝑢'𝑣𝑒 𝑠𝑤𝑖𝑡𝑐𝘩𝑒𝑑 𝑡𝑜 𝑡𝘩𝑒 𝑜𝑡𝘩𝑒𝑟 𝐵𝐴𝑆𝐼𝐶.
𝐹𝑜𝑟 𝑚𝑒, 𝑎𝑙𝑙 𝑚𝑦 𝑠𝑜𝑢𝑟𝑐𝑒 𝑐𝑜𝑑𝑒𝑠 𝑎𝑛𝑑 𝑖𝑚𝑝𝑜𝑟𝑡𝑎𝑛𝑡 𝑝𝑟𝑜𝑗𝑒𝑐𝑡𝑠 𝑎𝑟𝑒 𝑖𝑛 𝑃𝑜𝑤𝑒𝑟𝐵𝐴𝑆𝐼𝐶, 𝑠𝑜 𝐼 𝘩𝑎𝑣𝑒 𝑛𝑜 𝑐𝘩𝑜𝑖𝑐𝑒.
𝐼 𝑐𝑎𝑛'𝑡 𝑢𝑠𝑒 𝑎𝑛𝑦𝑡𝘩𝑖𝑛𝑔 𝑒𝑙𝑠𝑒 𝑟𝑖𝑔𝘩𝑡 𝑛𝑜𝑤, 𝑏𝑢𝑡 𝑖𝑓 𝐼 𝑐𝑜𝑢𝑙𝑑, 𝐼'𝑑 𝑑𝑒𝑓𝑖𝑛𝑖𝑡𝑒𝑙𝑦 𝑡𝑎𝑘𝑒 𝑎 𝑐𝑙𝑜𝑠𝑒𝑟 𝑙𝑜𝑜𝑘 𝑎𝑡 𝐶𝘩𝑎𝑟𝑙𝑒𝑠'𝑠 𝑐𝑜𝑚𝑝𝑖𝑙𝑒𝑟.
𝑊𝘩𝑦? 𝐵𝑒𝑐𝑎𝑢𝑠𝑒 𝑤𝑒 𝘩𝑎𝑣𝑒 𝑡𝘩𝑒 𝑠𝑜𝑢𝑟𝑐𝑒 𝑐𝑜𝑑𝑒 𝑡𝘩𝑒𝑟𝑒, 𝑎𝑙𝑙𝑜𝑤𝑖𝑛𝑔 𝑢𝑠 𝑡𝑜 𝑚𝑎𝑘𝑒 𝑎𝑑𝑗𝑢𝑠𝑡𝑚𝑒𝑛𝑡𝑠 𝑜𝑢𝑟𝑠𝑒𝑙𝑣𝑒𝑠.

𝐽ü𝑟𝑔𝑒𝑛 𝑖𝑠 𝑎𝑙𝑠𝑜 𝑚𝑎𝑘𝑖𝑛𝑔 𝑠𝑖𝑔𝑛𝑖𝑓𝑖𝑐𝑎𝑛𝑡 𝑝𝑟𝑜𝑔𝑟𝑒𝑠𝑠; 𝘩𝑒 𝑚𝑖𝑔𝘩𝑡 𝑐𝑟𝑒𝑎𝑡𝑒 𝑠𝑜𝑚𝑒𝑡𝘩𝑖𝑛𝑔 𝑡𝘩𝑎𝑡 𝑐𝑜𝑢𝑙𝑑 𝑏𝑒 𝑐𝑜𝑚𝑝𝑎𝑡𝑖𝑏𝑙𝑒 𝑤𝑖𝑡𝘩 𝑃𝑜𝑤𝑒𝑟𝐵𝐴𝑆𝐼𝐶.

𝑅𝑒𝑔𝑎𝑟𝑑𝑖𝑛𝑔 𝑡𝘩𝑒 10-𝑦𝑒𝑎𝑟 𝑠𝑝𝑎𝑛, 𝐼 𝑡𝘩𝑖𝑛𝑘 𝑡𝘩𝑎𝑡'𝑠 𝑎 𝑡𝘩𝑖𝑛𝑔 𝑜𝑓 𝑡𝘩𝑒 𝑝𝑎𝑠𝑡. 𝐼𝑛 𝑡𝑜𝑑𝑎𝑦'𝑠 𝐴𝐼 𝑒𝑟𝑎, 𝑠𝑜𝑚𝑒𝑜𝑛𝑒 𝑙𝑖𝑘𝑒 𝑦𝑜𝑢, 𝐽𝑜𝑠𝑒, 𝑐𝑜𝑢𝑙𝑑 𝑝𝑟𝑜𝑏𝑎𝑏𝑙𝑦 𝑑𝑒𝑣𝑒𝑙𝑜𝑝 𝑎 𝑐𝑜𝑚𝑝𝑖𝑙𝑒𝑟 𝑝𝑟𝑜𝑡𝑜𝑡𝑦𝑝𝑒 𝑤𝑖𝑡𝘩 𝑏𝑎𝑠𝑖𝑐 𝑑𝑎𝑡𝑎 𝑡𝑦𝑝𝑒𝑠 𝑖𝑛 𝑗𝑢𝑠𝑡 𝑡𝑤𝑜 𝑤𝑒𝑒𝑘𝑠.

𝑇𝘩𝑒 𝑏𝑖𝑔𝑔𝑒𝑟 𝑐𝘩𝑎𝑙𝑙𝑒𝑛𝑔𝑒 𝑖𝑠 𝑎𝑐𝑡𝑢𝑎𝑙𝑙𝑦 𝑡𝘩𝑒 𝑙𝑖𝑛𝑘𝑒𝑟.
𝑇𝘩𝑒 𝑐𝑜𝑚𝑝𝑖𝑙𝑒𝑟 𝑡𝘩𝑎𝑡 𝑔𝑒𝑛𝑒𝑟𝑎𝑡𝑒𝑠 𝑡𝘩𝑒 𝑎𝑠𝑠𝑒𝑚𝑏𝑙𝑦 𝑐𝑜𝑑𝑒 𝑖𝑠𝑛'𝑡 𝑡𝘩𝑒 𝑚𝑎𝑖𝑛 𝑖𝑠𝑠𝑢𝑒; 𝑚𝑜𝑠𝑡 𝑜𝑓 𝑡𝘩𝑎𝑡 𝑐𝑎𝑛 𝑛𝑜𝑤 𝑏𝑒 𝑑𝑜𝑛𝑒 𝑏𝑦 𝐴𝐼 𝑎𝑡 𝑡𝘩𝑒 𝑝𝑢𝑠𝘩 𝑜𝑓 𝑎 𝑏𝑢𝑡𝑡𝑜𝑛.
𝑌𝑜𝑢 𝑗𝑢𝑠𝑡 𝑠𝑎𝑦, "𝐻𝑒𝑦 𝐴𝐼, 𝑑𝑜 𝑡𝘩𝑖𝑠," 𝑎𝑛𝑑 𝑦𝑜𝑢 𝑔𝑒𝑡 𝑎𝑙𝑚𝑜𝑠𝑡 𝑓𝑖𝑛𝑖𝑠𝘩𝑒𝑑 𝑎𝑠𝑠𝑒𝑚𝑏𝑙𝑦 𝑐𝑜𝑑𝑒, 𝑤𝘩𝑖𝑐𝘩 𝑦𝑜𝑢 𝑐𝑎𝑛 𝑟𝑒𝑣𝑖𝑒𝑤 𝑎𝑛𝑑 𝑐𝑜𝑟𝑟𝑒𝑐𝑡 𝑏𝑒𝑓𝑜𝑟𝑒 𝑢𝑠𝑖𝑛𝑔. 𝐼𝑡'𝑠 𝑛𝑜 𝑙𝑜𝑛𝑔𝑒𝑟 𝑎 𝑚𝑎𝑡𝑡𝑒𝑟 𝑜𝑓 𝑤𝑟𝑖𝑡𝑖𝑛𝑔 𝑒𝑣𝑒𝑟𝑦𝑡𝘩𝑖𝑛𝑔 𝑏𝑦 𝘩𝑎𝑛𝑑—𝑡𝘩𝑒 𝐴𝐼 𝑡𝑎𝑘𝑒𝑠 𝑐𝑎𝑟𝑒 𝑜𝑓 𝑡𝘩𝑎𝑡.

𝑇𝘩𝑒 𝑟𝑒𝑎𝑙 𝑝𝑟𝑜𝑏𝑙𝑒𝑚 𝑙𝑖𝑒𝑠 𝑤𝑖𝑡𝘩 𝑡𝘩𝑒 𝑙𝑖𝑛𝑘𝑒𝑟, 𝑎𝑠 𝑡𝘩𝑒𝑟𝑒 𝑎𝑟𝑒 𝑣𝑎𝑟𝑖𝑜𝑢𝑠 𝑠𝑡𝑎𝑛𝑑𝑎𝑟𝑑𝑠 𝑖𝑛𝑣𝑜𝑙𝑣𝑒𝑑, 𝑚𝑎𝑘𝑖𝑛𝑔 𝑖𝑡 𝑎 𝑑𝑒𝑒𝑝𝑒𝑟 𝑡𝑜𝑝𝑖𝑐 𝑡𝑜 𝑒𝑥𝑝𝑙𝑜𝑟𝑒.

𝐻𝑜𝑤𝑒𝑣𝑒𝑟, 𝑖𝑓 𝑦𝑜𝑢 𝑘𝑛𝑜𝑤 𝑤𝘩𝑎𝑡 𝑦𝑜𝑢 𝑤𝑎𝑛𝑡, 𝐴𝐼 𝑐𝑎𝑛 𝑔𝑟𝑒𝑎𝑡𝑙𝑦 𝑎𝑠𝑠𝑖𝑠𝑡 𝑖𝑛 𝑡𝘩𝑒 𝑝𝑟𝑜𝑐𝑒𝑠𝑠.
𝑆𝑜, 𝑐𝑟𝑒𝑎𝑡𝑖𝑛𝑔 𝑎 𝑐𝑜𝑚𝑝𝑖𝑙𝑒𝑟 𝑡𝑜𝑑𝑎𝑦 𝑖𝑠 𝑛𝑜𝑡 𝑎 10-𝑦𝑒𝑎𝑟 𝑒𝑛𝑑𝑒𝑎𝑣𝑜𝑟, 𝑒𝑠𝑝𝑒𝑐𝑖𝑎𝑙𝑙𝑦 𝑖𝑓 𝑖𝑡'𝑠 𝑗𝑢𝑠𝑡 𝑜𝑛𝑒 𝑝𝑒𝑟𝑠𝑜𝑛 𝑤𝑜𝑟𝑘𝑖𝑛𝑔 𝑜𝑛 𝑖𝑡.
𝑇𝘩𝑒 𝑝𝑟𝑖𝑛𝑐𝑖𝑝𝑙𝑒 𝑖𝑠 𝑐𝑙𝑒𝑎𝑟: 𝑝𝑢𝑡 𝑎𝑙𝑙 𝑒𝑠𝑠𝑒𝑛𝑡𝑖𝑎𝑙 𝑓𝑒𝑎𝑡𝑢𝑟𝑒𝑠 𝑖𝑛 𝑡𝘩𝑒 𝑐𝑜𝑚𝑝𝑖𝑙𝑒𝑟 𝑎𝑛𝑑 𝑒𝑣𝑒𝑟𝑦𝑡𝘩𝑖𝑛𝑔 𝑒𝑙𝑠𝑒 𝑖𝑛 𝑙𝑖𝑏𝑟𝑎𝑟𝑖𝑒𝑠.

𝐼'𝑑 𝑙𝑖𝑘𝑒 𝑡𝑜 𝑎𝑑𝑑 𝑡𝘩𝑎𝑡 𝑓𝑜𝑟 𝑐𝑒𝑟𝑡𝑎𝑖𝑛 𝑡𝑎𝑠𝑘𝑠 𝑟𝑒𝑞𝑢𝑖𝑟𝑖𝑛𝑔 𝑟𝑒𝑎𝑑𝑦-𝑚𝑎𝑑𝑒 𝑙𝑖𝑏𝑟𝑎𝑟𝑖𝑒𝑠, 𝐼 𝑎𝑙𝑠𝑜 𝑒𝑛𝑗𝑜𝑦 𝑢𝑠𝑖𝑛𝑔 𝑃𝑢𝑟𝑒𝐵𝑎𝑠𝑖𝑐.
𝐴𝑠 𝑦𝑜𝑢'𝑣𝑒 𝑚𝑒𝑛𝑡𝑖𝑜𝑛𝑒𝑑 𝑏𝑒𝑓𝑜𝑟𝑒, 𝑃𝑢𝑟𝑒𝐵𝑎𝑠𝑖𝑐 𝑖𝑠 𝑒𝑠𝑠𝑒𝑛𝑡𝑖𝑎𝑙𝑙𝑦 𝑎 𝑚𝑎𝑐𝑟𝑜 𝑐𝑜𝑚𝑝𝑖𝑙𝑒𝑟 𝑎𝑛𝑑 𝑛𝑜𝑡 𝑎 𝑡𝑟𝑢𝑒 𝐵𝑎𝑠𝑖𝑐 𝑙𝑎𝑛𝑔𝑢𝑎𝑔𝑒, 𝑎 𝑓𝑎𝑐𝑡 𝑡𝘩𝑎𝑡 𝑟𝑒𝑚𝑎𝑖𝑛𝑠 𝑢𝑛𝑐𝘩𝑎𝑛𝑔𝑒𝑑 𝑡𝑜𝑑𝑎𝑦.
𝐻𝑜𝑤𝑒𝑣𝑒𝑟, 𝑖𝑡 𝑜𝑓𝑓𝑒𝑟𝑠 𝑙𝑖𝑏𝑟𝑎𝑟𝑖𝑒𝑠 𝑡𝘩𝑎𝑡 𝑔𝑟𝑒𝑎𝑡𝑙𝑦 𝑠𝑖𝑚𝑝𝑙𝑖𝑓𝑦 𝑤𝑜𝑟𝑘 𝑓𝑜𝑟 𝑠𝑝𝑒𝑐𝑖𝑓𝑖𝑐 𝑝𝑟𝑜𝑗𝑒𝑐𝑡𝑠.

𝑇𝘩𝑖𝑠 𝑖𝑠 𝑝𝑎𝑟𝑡𝑖𝑐𝑢𝑙𝑎𝑟𝑙𝑦 𝑟𝑒𝑙𝑒𝑣𝑎𝑛𝑡 𝑐𝑜𝑚𝑝𝑎𝑟𝑒𝑑 𝑡𝑜 𝑤𝘩𝑎𝑡 𝑃𝑜𝑤𝑒𝑟𝐵𝑎𝑠𝑖𝑐 𝑜𝑓𝑡𝑒𝑛 𝑙𝑎𝑐𝑘𝑠—𝑒𝑥𝑐𝑒𝑝𝑡, 𝑜𝑓 𝑐𝑜𝑢𝑟𝑠𝑒, 𝑓𝑜𝑟 𝑦𝑜𝑢𝑟 𝑙𝑖𝑏𝑟𝑎𝑟𝑖𝑒𝑠, 𝑤𝘩𝑖𝑐𝘩 𝑎𝑟𝑒 𝑡𝘩𝑒 𝑒𝑥𝑐𝑒𝑝𝑡𝑖𝑜𝑛—𝑤𝘩𝑒𝑟𝑒 𝘩𝑎𝑣𝑖𝑛𝑔 𝑎𝑛 𝐻𝑇𝑇𝑃 𝑜𝑟 𝐽𝑆𝑂𝑁 𝑙𝑖𝑏𝑟𝑎𝑟𝑦 𝑖𝑠 𝑐𝑟𝑢𝑐𝑖𝑎𝑙.

𝐴𝑑𝑑𝑖𝑡𝑖𝑜𝑛𝑎𝑙𝑙𝑦, 𝐴𝐼 𝘩𝑎𝑛𝑑𝑙𝑒𝑠 𝑃𝑢𝑟𝑒𝐵𝑎𝑠𝑖𝑐 𝑣𝑒𝑟𝑦 𝑤𝑒𝑙𝑙, 𝑚𝑒𝑎𝑛𝑖𝑛𝑔 𝑚𝑎𝑛𝑦 𝐴𝐼 𝑡𝑜𝑜𝑙𝑠 𝑐𝑎𝑛 𝑝𝑟𝑜𝑑𝑢𝑐𝑒 𝑃𝑢𝑟𝑒𝐵𝑎𝑠𝑖𝑐 𝑐𝑜𝑑𝑒 𝑡𝘩𝑎𝑡 𝑖𝑠 𝑎𝑙𝑚𝑜𝑠𝑡 𝑝𝑟𝑜𝑑𝑢𝑐𝑡𝑖𝑜𝑛-𝑟𝑒𝑎𝑑𝑦.
𝑌𝑜𝑢 𝑐𝑎𝑛 𝑎𝑠𝑠𝑖𝑔𝑛 𝑟𝑒𝑎𝑙𝑙𝑦 𝑐𝑜𝑚𝑝𝑙𝑒𝑥 𝑡𝑎𝑠𝑘𝑠, 𝑙𝑖𝑘𝑒 𝘩𝑎𝑣𝑖𝑛𝑔 𝑎𝑛 𝐴𝐼 𝑎𝑛𝑎𝑙𝑦𝑧𝑒 𝑜𝑢𝑡𝑝𝑢𝑡, 𝑎𝑛𝑑 𝑖𝑡 𝑐𝑎𝑛 𝑓𝑜𝑟𝑚𝑢𝑙𝑎𝑡𝑒 𝑡𝘩𝑎𝑡 𝑖𝑛 𝑃𝑢𝑟𝑒𝐵𝑎𝑠𝑖𝑐.
𝐼'𝑚 𝑛𝑜𝑡 𝑠𝑢𝑟𝑒 𝑤𝘩𝑦 𝑠𝑜𝑚𝑒 𝐴𝐼𝑠 𝑠𝑒𝑒𝑚 𝑡𝑜 𝑝𝑒𝑟𝑓𝑜𝑟𝑚 𝑏𝑒𝑡𝑡𝑒𝑟 𝑖𝑛 𝑃𝑢𝑟𝑒𝐵𝑎𝑠𝑖𝑐 𝑡𝘩𝑎𝑛 𝑖𝑛 𝑃𝑜𝑤𝑒𝑟𝐵𝑎𝑠𝑖𝑐, 𝑏𝑢𝑡 𝑖𝑡 𝑚𝑖𝑔𝘩𝑡 𝑏𝑒 𝑑𝑢𝑒 𝑡𝑜 𝑃𝑢𝑟𝑒𝐵𝑎𝑠𝑖𝑐'𝑠 𝑚𝑜𝑟𝑒 𝐶-𝑙𝑖𝑘𝑒 𝑠𝑦𝑛𝑡𝑎𝑥, 𝑤𝘩𝑖𝑐𝘩 𝑐𝑎𝑛 𝑎𝑙𝑠𝑜 𝑏𝑒 𝑎 𝑑𝑟𝑎𝑤𝑏𝑎𝑐𝑘.

𝑂𝑛 𝑎 𝑠𝑖𝑑𝑒 𝑛𝑜𝑡𝑒, 𝐼 𝑟𝑒𝑎𝑙𝑙𝑦 𝑒𝑛𝑗𝑜𝑦 𝑖𝑡 𝑤𝘩𝑒𝑛 𝑦𝑜𝑢 𝑜𝑐𝑐𝑎𝑠𝑖𝑜𝑛𝑎𝑙𝑙𝑦 𝑐𝑜𝑚𝑒 𝑏𝑦, 𝑝𝑟𝑜𝑔𝑟𝑎𝑚, 𝑎𝑛𝑑 𝑤𝑟𝑖𝑡𝑒 𝑎 𝑏𝑖𝑡.
𝐼𝑡'𝑠 𝑎 𝑔𝑟𝑒𝑎𝑡 𝑒𝑛𝑟𝑖𝑐𝘩𝑚𝑒𝑛𝑡 𝑓𝑜𝑟 𝑢𝑠 𝑎𝑛𝑑 𝑎 𝑙𝑜𝑣𝑒𝑙𝑦 𝑟𝑒𝑚𝑖𝑛𝑑𝑒𝑟 𝑜𝑓 𝑡𝘩𝑒 𝑜𝑙𝑑 𝑡𝑖𝑚𝑒𝑠.


#𝑃𝑜𝑤𝑒𝑟𝐵𝐴𝑆𝐼𝐶 #𝐶𝑜𝑚𝑝𝑖𝑙𝑒𝑟𝐷𝑒𝑣𝑒𝑙𝑜𝑝𝑚𝑒𝑛𝑡 #𝐴𝑟𝑡𝑖𝑓𝑖𝑐𝑖𝑎𝑙𝐼𝑛𝑡𝑒𝑙𝑙𝑖𝑔𝑒𝑛𝑐𝑒 #𝑃𝑟𝑜𝑔𝑟𝑎𝑚𝑚𝑖𝑛𝑔𝐶𝑜𝑚𝑚𝑢𝑛𝑖𝑡𝑦 #𝑁𝑜𝑠𝑡𝑎𝑙𝑔𝑖𝑎

[José Roca]

> 𝐼'𝑚 𝑛𝑎𝑡𝑢𝑟𝑎𝑙𝑙𝑦 𝑑𝑖𝑠𝑎𝑝𝑝𝑜𝑖𝑛𝑡𝑒𝑑 𝑡𝘩𝑎𝑡 𝑦𝑜𝑢'𝑣𝑒 𝑠𝑤𝑖𝑡𝑐𝘩𝑒𝑑 𝑡𝑜 𝑡𝘩𝑒 𝑜𝑡𝘩𝑒𝑟 𝐵𝐴𝑆𝐼𝐶.

What choice did I have? PowerBasic is dead.

I don't like PureBasic. It has an horrible syntax. Don't know why it is called "Pure".

> 𝑅𝑒𝑔𝑎𝑟𝑑𝑖𝑛𝑔 𝑡𝘩𝑒 10-𝑦𝑒𝑎𝑟 𝑠𝑝𝑎𝑛, 𝐼 𝑡𝘩𝑖𝑛𝑘 𝑡𝘩𝑎𝑡'𝑠 𝑎 𝑡𝘩𝑖𝑛𝑔 𝑜𝑓 𝑡𝘩𝑒 𝑝𝑎𝑠𝑡. 𝐼𝑛 𝑡𝑜𝑑𝑎𝑦'𝑠 𝐴𝐼 𝑒𝑟𝑎, 𝑠𝑜𝑚𝑒𝑜𝑛𝑒 𝑙𝑖𝑘𝑒 𝑦𝑜𝑢, 𝐽𝑜𝑠𝑒, 𝑐𝑜𝑢𝑙𝑑 𝑝𝑟𝑜𝑏𝑎𝑏𝑙𝑦 𝑑𝑒𝑣𝑒𝑙𝑜𝑝 𝑎 𝑐𝑜𝑚𝑝𝑖𝑙𝑒𝑟 𝑝𝑟𝑜𝑡𝑜𝑡𝑦𝑝𝑒 𝑤𝑖𝑡𝘩 𝑏𝑎𝑠𝑖𝑐 𝑑𝑎𝑡𝑎 𝑡𝑦𝑝𝑒𝑠 𝑖𝑛 𝑗𝑢𝑠𝑡 𝑡𝑤𝑜 𝑤𝑒𝑒𝑘𝑠.

Why bother?

> 𝑇𝘩𝑒 𝑝𝑟𝑖𝑛𝑐𝑖𝑝𝑙𝑒 𝑖𝑠 𝑐𝑙𝑒𝑎𝑟: 𝑝𝑢𝑡 𝑎𝑙𝑙 𝑒𝑠𝑠𝑒𝑛𝑡𝑖𝑎𝑙 𝑓𝑒𝑎𝑡𝑢𝑟𝑒𝑠 𝑖𝑛 𝑡𝘩𝑒 𝑐𝑜𝑚𝑝𝑖𝑙𝑒𝑟 𝑎𝑛𝑑 𝑒𝑣𝑒𝑟𝑦𝑡𝘩𝑖𝑛𝑔 𝑒𝑙𝑠𝑒 𝑖𝑛 𝑙𝑖𝑏𝑟𝑎𝑟𝑖𝑒𝑠.

I already have a compiler that I like, providing the essential and much more. For the lacking features, I write classes, like I'm doing now.

[Frank Brübach]

Year 2025: That will took some time to get the  final result for this simple example below by an interpreter and compiler I think
 minimum half of a year until one year for a first release.. my Personal opinion..

'

Code Select Expand

dim a,b,c as long
dim s as string

a=10:b=20:c=a*b
s="Hello NewBasic " & c

print s
'
 you need a lexer(tokenizer input), parser, semantic and syntax analyzer, code optimizer (performance)
 and code generator (translation to machine code).
 
 last not least you need a good IDE.
 
 there are some tools That Can Help (parser, lexer, compiler tools)

 handcoding with manpower: if you are planing to do all from Scratch: This could take several months to a year or more.

 support by an AI you need some good programmer to adept complexed written code for corrections and error handling

 you need support for a good documentation, a nice engaged forum, beta tester much more...

 this can take three to six month in my eyes to build a first version

 Using existing tools (other compiler for example) can significantly speed up the process at all

 Implement basic optimizations to improve the performance of the generated code and

 testing and debugging the compiler to ensure it works correctly across different platforms is a final step

 realistical timeline (for advanced user and programmers!)

 Week 1-4: Define the language grammar and set up the lexer and parser.

 Week 5-7: Implement semantic analysis and build the intermediate representation

 Week 8-10: Work on basic optimizations and implementations

 Week 11-14: Implement code generation

 Week 15-18: Testing and debugging

 all in all about three to six month minimum continous work at the compiler

 you cant do this Work Alone I guess you need 3 - 4 persons for this job

'
 kind regards, frank

[Charles Pegge]

A new compiler made by a man alone is a project of at least 10 years (ask Charles). I'm too old to wait. FreeBasic offers what I need and all the code that I write can be compiled to 32 or 64 bit without changes.

I think the two weeks spent creating a Basic compiler would soon turn into 10 years. In my case it is 17 years . But the satisfaction is immense, and I am constantly discovering new ways of doing things. I've also been able to incorporate some of the awkward fringe features like passing and returning UDTs byval.

I'm not sure what to make of PowerBasic. Is it worth reviving? Is it worth building and maintaining a compatibility library?

[Theo Gottwald]

To understand my journey, Charles, you need to know the whole story. I started with the Atari 400 and Atari BASIC, a language packed in just 8 KB of ROM for the 8-bit 6502 processor. Back then, we already had concepts like "Goes Up" and "Return," along with variables, addition and subtraction, and commands like Peek and Poke.

For faster operations, we had the USR command to call machine code. This is where my programming journey began, and I've built upon it ever since.

What I loved about Power BASIC and procedural programming was the ability to take functional components, name them, and assemble something greater, much like building blocks.

This concept still fascinates me today!
Yet, there's often the challenge of naming those components, as many names have already been taken over time.
So it is missing "Namespaces", i call them Modules.

The fantastic thing is that the same concept still works today, though I wish certain features were expanded.

For instance, I'd love functions that can return multiple results, similar to using two Ref parameters but more straightforward. I once suggested genuine parameters for threads —not just one parameter, but the ability to pass any number of parameters like a function or procedure. Bob did something but it never really worked.
Anyway, I could achieve this with objects later, but frequent calls often led to memory leaks, especially with Power BASIC objects.

I come from the old school of simple BASIC, and one has to understand that. I've dabbled in C and other modular languages, but my thought processes have developed in specific ways. By the way, Jose is right: Power BASIC is more of a macro compiler, yet it has incredible libraries. For many modern needs, a simple subroutine from a Pure BASIC library can do half the work, which results in significant efficiency.

When considering a programming language, it's crucial to remember that while a language might be good, it needs libraries to solve real problems easily.

Understanding my journey means seeing the path from the 8-bit Atari 400, through various stages, to Power BASIC—a dream come true for me back then. I still take joy in how far I've come and in grasping how it all works together.

I also want to mention that I appreciate having direct contact with the people who can tweak a compiler. In case of errors or when specific features are needed, it's invaluable to reach out directly to them. This is very interesting to me and is one of the main reasons I really like Charles's Oxygen Basic, aside from its excellent macro capabilities.

Creating a basic compiler isn't as daunting as it once was. It's worth noting how many tiny BASIC and Small BASIC compilers are floating around out there. Sure, some may be interpreters, but many are indeed compilers, typically developed in a relatively short period. Moreover, if you have a clear understanding of which subprograms and parameters you need, you don't have to create them from scratch. Once you can describe it clearly and outline a precise plan, which is often the main challenge, you can hand it over to AI. Today's AI systems can essentially automate this process; they can write code efficiently. While a complete solution in Python might be feasible, AI systems have become quite proficient at working with ASM as well.
In response to your comment, Charles, I want to emphasize that a machine-generated compiler program is certainly not as refined and perfect as one you have been improving over the last 10 years based on practical observations. There is a significant difference; it's simply a tool where you input code at the top and get the combined assembly code output at the bottom. And then, of course, the optimization phase begins, which always requires time.

#CompilerDevelopment #MachineLearning #CodeOptimization #SoftwareEngineering #AIProgramming
#Compiler #Programming #AI #Coding #Automation
#OxygenBasic #CompilerDevelopment #ProgrammingCommunity #MacroCapabilities #CharlesOxygen

🌟💻👾✨

#ProgrammingJourney #Atari400 #PowerBASIC #Coding #RetroGaming #TechHistory 🎮🚀🧩💡

[José Roca]

Enough of this daydreaming. Too many people expounding theories and asking others to do the work. If AI is so wonderful, ask it to make you a compiler to your liking. I'm still waiting for the damn AI to give me a worthwhile answer.

[José Roca]

I have asked Copilot: "Give me code to implement a rich edit ole callback with FreeBasic".

And it has answered:

Code Select Expand

#include "windows.bi"
#include "richedit.bi"
#include "commctrl.bi"

' OLE callback function
function RichEditOleCallback(byval lpParam as LPDATAOBJECT, byval iob as long, byval ppt as LPPOINTL, byval pFlags as long) as HRESULT
    ' Example: handle the callback
    print "OLE callback function called."
    return S_OK
end function

' Main function
sub Main()
    dim hInstance as HINSTANCE
    dim hWnd as HWND
    dim hRichEdit as HWND

    hInstance = GetModuleHandle(NULL)

    ' Initialize Rich Edit control
    LoadLibrary("riched20.dll")

    ' Create a window class
    dim wc as WNDCLASS
    wc.style = CS_HREDRAW or CS_VREDRAW
    wc.lpfnWndProc = @DefWindowProc
    wc.cbClsExtra = 0
    wc.cbWndExtra = 0
    wc.hInstance = hInstance
    wc.hIcon = LoadIcon(NULL, IDI_APPLICATION)
    wc.hCursor = LoadCursor(NULL, IDC_ARROW)
    wc.hbrBackground = cast(HBRUSH, COLOR_WINDOW + 1)
    wc.lpszMenuName = NULL
    wc.lpszClassName = strptr("RichEditOLECallback")

    RegisterClass(@wc)

    ' Create main window
    hWnd = CreateWindowEx(0, strptr("RichEditOLECallback"), strptr("Rich Edit OLE Callback Example"), WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 800, 600, NULL, NULL, hInstance, NULL)

    ' Create Rich Edit control
    hRichEdit = CreateWindowEx(0, RICHEDIT_CLASS, "", WS_CHILD or WS_VISIBLE or WS_BORDER or ES_MULTILINE or ES_AUTOVSCROLL, 10, 10, 780, 580, hWnd, NULL, hInstance, NULL)

    ' Set OLE callback
    dim pOleCallback as IRichEditOleCallback ptr
    pOleCallback = @RichEditOleCallback
    SendMessage(hRichEdit, EM_SETOLECALLBACK, 0, cast(LPARAM, pOleCallback))

    ' Show window
    ShowWindow(hWnd, SW_SHOW)
    UpdateWindow(hWnd)

    ' Message loop
    dim msg as MSG
    while GetMessage(@msg, NULL, 0, 0)
        TranslateMessage(@msg)
        DispatchMessage(@msg)
    wend
end sub

Main()

Let's see...

Code Select Expand

' OLE callback function
function RichEditOleCallback(byval lpParam as LPDATAOBJECT, byval iob as long, byval ppt as LPPOINTL, byval pFlags as long) as HRESULT
    ' Example: handle the callback
    print "OLE callback function called."
    return S_OK
end function

Invented parameters [(byval lpParam as LPDATAOBJECT, byval iob as long, byval ppt as LPPOINTL, byval pFlags as long)] and no code in the callback. Very helpful!

[José Roca]

Back to things that matter. I'm going to implement the ITExtDocument2 interface inside of the CRichEditCtl class.

I can retrieve a pointer to this interface of the document object that creates the rich edit control with this method:

Code Select Expand

' ========================================================================================
' Retrieves a pointer to the ITextDocument2 interface
' ========================================================================================
PRIVATE FUNCTION CRichEditCtrl.GetDocInterface () AS ITextDocument2 PTR
   ' // Retrieve a pointer to the IRichEditOle interface of the rich edit control
   DIM pUnk AS IUnknown PTR, pTextDocument2 AS ITextDocument2 PTR
   this.SetResult(SendMessageW(hRichEdit, EM_GETOLEINTERFACE, 0, cast(LPARAM, @pUnk)))
   ' // Retrieve a pointer to its ITextDocument2 interface
   IF pUnk THEN
      DIM IID_ITextDocument2_ AS IID = AfxGuid(AFX_IID_ITextDocument2)
      this.SetResult(IUnknown_QueryInterface(pUnk, @IID_ITextDocument2_, @pTextDocument2))
      IUnknown_Release(pUnk)
   END IF
   RETURN pTextDocument2
END FUNCTION
' ========================================================================================

The question is: "To be or not to be?", sorry  , I mean, to store this pointer in an instance variable or to retrieve it each time that I call a ITextDocument2 method just in case it has changed. Don't know if some action could make the rich edit control to destroy the document object and create a new one or if the document object remains the same for the life of the rich edit control. The MSDN documentation does not provide this information.

I have made test with the two ITextDocument2 interface that potentially could change it: Open and New.

Open: Opens a new document. If another document is open, this method saves any current changes and closes the current document before opening a new one.

New: Opens a new document.

The difference is that, besides closing the current document, Open loads the specified file.

Neither Open, nor New, change the interface pointer. They reuse the existing document object.

Getting a document interface pointer each time I call a ITextDocument2 method will be a bit slower (although not much) but safer. If i cache the value of the pointer the application would crash if it changes for some reason.

Does AI something to say?