• Welcome to PlanetSquires Forums.
 

José, if you're bored...

Started by Paul Squires, August 02, 2018, 09:19:19 PM

Previous topic - Next topic

Paul Squires

I'm updating all of the WinFBE and WinFormsX code regarding those new CAST warnings.

Cast(WNDPROC, @wfxApplication.SubclassProc)
To:
Cast(SUBCLASSPROC, @wfxApplication.SubclassProc)

I have already combined both 32 and 64 bit compilers into one folder. Once we get our source code playing nice with the new compiler then I will look at upgrading the GCC files (cc1) to the latest version. I know that David Roberts has been playing with this in his builds so I may have to post some questions to see if there are any gotchas I need to be aware of.

Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

Paul Squires

I have made all of the necessary changes to both WinFBE and the WinFormsX code (that WinFBE's visual designer uses). Everything now compiles perfectly using the latest nightly build FB compiler and Jose's WinFBX includes. I may wait until tomorrow before posting an updated WinFBE_Suite just in case more CAST warning areas are discovered.
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

José Roca

I did choose WNDPROC instead of SUBCLASSPROC because at the time I wrote CWindow I used SetWindowLongPtrW for subclassing. Later, when I implemented the new subclassing method with SetWindowSubclass i thought that just casting it to SUBCLASSPROC was enough, and it worked until now.

Paul Squires

I have also updated GCC to 8.1 for both 32 and 64 bit. Seems to be working fine.
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

Joerg B.

Hello Together

The discussion and the contributions in the FB Forum regarding the stricter type checks, become (in my opinion) increasingly emotional.
Rational arguments are (again in my opinion) much more effective for a solution.
So I am only insecure in which direction the ship is heading.

Or in other words...

The developers are at the crossroads and do not yet know in which direction they should turn.
Greeting from Germany

Joerg

Paul Squires

I am confident that CoderJeff, fxm, and dkl will make the best decision possible given all of the factors related warnings and the new CONST code that they have been adding over the last month or so. The rest of the conversation is, like you say, just emotional reactions. I wouldn't worry about this issue affecting development.
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

José Roca

As I write reusable code, that must work with no matter which options the user chooses to compile, I need all the warnings. The problem are the beginners, that have a tendency to leave at the first difficulty.

Joerg B.

#142
Hola José
Now there is an updated dos and win64 version based on your post for download.  ;D
I download it and see what messages are coming now.
Greeting from Germany

Joerg

José Roca

According the CoderJeff's post:

- added '-w none' option to suppress warnings. 'none' is based on warning level and is a better way of saying '-w <level>' where level has sufficiently high value to suppress warnings...etc
- warnings generated by default now are same again as fbc 1.05/pre-August 1.06
- warnings generated with '-w pedantic' now are same again as fbc 1.05/pre-August 1.06
- '-w all' will show the additional function pointer warnings
- '-w funcptr' implies '-w all' and will show function pointer warnings, inside CAST()/CPTR() also
- '-w constness' implies '-w funcptr' and will show const discarded warnings

-w none is what I have suggested.

This will make life easier to beginners, that don't know how to solve these warnings.

Be aware that if somebody intends to write reusable code it should use -w all and resolve all the conflicts to avoid warnings when used by somebody that won't use -w none.


José Roca

#144
Added CMemStream and CMemTextStream classes to CStream.inc.

CMemStream is suited to work with byte arrays and CMemTextStream is tailored to work with unicode strings (can be used as a fast string builder).

I wanted to have them implemented because streams are used very often in COM programming.

I also have ported most of the documentation to the .md format:
https://github.com/JoseRoca/WinFBX/tree/master/docs

And a new .chm file with many corrections is available at:
https://github.com/JoseRoca/WinFBX/tree/master/Help


José Roca

Tomorrow I will explore the ADO Stream interface. With some additional wrappers I think it can offer a good alternative to all the previous stream classes in which I have been working.

1. It can work with ansi, unicode and utf-8 text files, terminated with CRLF, CR or LF.

2. It can work with binary files.

3. It can work in memory.

Since the ADO stream is not compatible with the standard IStream interface, I still will need the previous classes for some tasks, but to work with files and with the memory, the ADO streams seems to cover all.

Paul Squires

Interesting. I look forward to seeing what the ADO stream is all about and if it will be easier to use than the IStream code I'm using from you now.
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

José Roca

#147
Maybe there is not need to change anything or very little, unless you have suggestions. Maybe an overloaded Open method with a parameter for the opening mode (Read, Write, etc.). The main advantage is than one class fits all and that the AfxGetOleErrorInfo function (sort of GetLastResult for COM) will return a localized description of the error (much better than just getting an error code). I wonder why I haven't remembered until now that ADO has a Stream interface that can work with files (maybe because I always have associated the use of ADO with databases). It can also be used to open and save files from the web. LoadFromFile not only works with unicode paths, but also accepts any valid path and name in UNC format.

This opens an stream in memory. If we don't specify the Type_, Charset and LineSeparator properties, the defaults are a Windows unicode text file.


'#CONSOLE ON
#define UNICODE
#include "Afx/CADODB/CADODB.inc"
USING Afx

' // Open a stream in memory
DIM pStream AS CAdoStream
pStream.Type_ = adTypeText   ' We can also use adTypeBinary. Default is adTypeText.
pStream.Charset = "unicode"   ' We can also use "ascii", "utf-8" and other encondings. Default is unicode.
pStream.LineSeparator = adCRLF   ' We can also use LF (for Linux files) or CR (for Mac files). Default is adCRLF.
pStream.Open

' // Write some text to it (adWriteLine writes a line and a line separator). The default is adWriteChar, that writes
' // the line without a line separator.
pStream.WriteText "This is a test string", adWriteLine
pStream.WriteText "This is another test string", adWriteLine

' // Set the position at the beginning of the file
pStream.Position = 0
' // Read the lines sequentially. If we don't specify adReadLine or we specify adReadAll (the deault), it will read all the lines
DIM cbsText AS CBSTR = pStream.ReadText(adReadLine)
print cbsText
cbsText = pStream.ReadText(adReadLine)
print cbsText

' // Save the contents to a file
pStream.SaveToFile "TestStream.txt", adSaveCreateOverWrite
pStream.Close


This loads a file in binary mode


' // Open a stream
DIM pStream AS CAdoStream
pStream.Charset = "ascii"
pStream.Type_ = adTypeBinary
pStream.Open
pStream.LoadFromFile(AfxGetExePath & "\TextA1.txt")
IF pStream.GetLastResult THEN print AfxGetOleErrorInfo
DIM cv AS CVAR = pStream.Read   ' // You can specify the number of bytes to read
print cv.ToBuffer


ToBuffer returns the contents of the file as a FreeBasic string used as a byte array buffer. An overloaded ToBuffer method allows you to pass a pointer to any kind of buffer and the length of the buffer.

The Write method writes binary data to the stream and WriteText writes strings.

The Write method uses a variant. You can use the CVAR data type for it. It has methods to allow to use almost any data type, even arrays.

The Mode property indicates the permissions:

adModeRead : Indicates read-only permissions.
adModeReadWrite : Indicates read/write permissions.
adModeShareDenyNone : Allows others to open a connection with any permissions. Neither read nor write access can be denied to others.
adModeShareDenyRead : Prevents others from opening a connection with read permissions
adModeShareDenyWrite : Prevents others from opening a connection with write permissions.
adModeShareExclusive : Prevents others from opening a connection.
adModeUnknown : Default. Indicates that the permissions have not yet been set or cannot be determined.
adModeWrite : Indicates write-only permissions.

Other properties include EOS and SetEOS, to get and set the end of the stream; Size, to get the size of the stream in number of bytes; Position, a value that specifies the offset, in number of bytes, of the current position from the beginning of the stream (a value of 0 represents the first byte in the stream).

For text streams, SkipLine, skips one entire line when reading a text stream.

Looks like we have a very good alternative to work with files.

José Roca

Apparently it only works in memory, not directly with the disk file. It remains as a good alternative to work with memory streams.

José Roca

I have added documentation about CAdoStream (excluding information about URLs and Record objects to avoid confusions) as an alternative to the CMemStream class, in my GitHub repository:

https://github.com/JoseRoca/WinFBX/blob/master/docs/File%20Management/CMemStream%20Class.md