Author Topic: FreeBASIC CWstr  (Read 4153 times)

0 Members and 1 Guest are viewing this topic.

Offline José Roca

  • Administrator
  • Hero Member
  • *****
  • Posts: 2456
    • José Roca Software
Re: FreeBASIC CWstr
« Reply #90 on: May 28, 2018, 08:10:08 PM »
> As long as "p" in "someprop" is an IN parameter, this will work in general (because of the intermediately created CBstr) - is this correct?

Of course. What I mean is that if you intend to call, for example, the GetParentFolderName of the IFileSystem object

GetParentFolderName (BYVAL Path AS BSTR, BYVAL pbstrResult AS BSTR PTR) AS HRESULT

you have to pass a BSTR with the path and the address of another BSTR to receive the result, and if they aren't true BSTRings it won't work. You can't declare the parameters as CBSTR instead of BSTR because the called method has no idea of what a CBSTR is, and you can't declare these parameters as WSTRINGs because it will fail. What you can do is to pass cbsPath.bptr and cbsRes.vptr.

« Last Edit: May 28, 2018, 08:14:26 PM by José Roca »

Offline Juergen Kuehlwein

  • Jr. Member
  • **
  • Posts: 54
Re: FreeBASIC CWstr
« Reply #91 on: May 28, 2018, 11:16:20 PM »
José,


i don´t intend to call GetparentFolderName directly, i would use the wrapper function your framework supplies, which conveniently accepts CBstrs:


Quote
PRIVATE FUNCTION CFileSys.GetParentFolderName (BYREF cbsFolder AS CBSTR) AS CBSTR


and i would call it like this


Quote
p = <CFileSys>.GetParentFolderName(f)


where p MUST be a CBstr, and f can be a CBstr, CWstr, WSTRING, String and ZSTRING (and if i define USTRING as CWstr, a USTRING as well).


I didn´t find one single instance, where a BSTR is needed as parameter of a procedure i could call directly. As it seems, it is used internally alone. So when using your framework i can get away with a CWstr most of the time and sometimes (only in COM) i MUST use a CBStr for IN/OUT parameters (CBstr.vptr) and for returned strings (CBstr).

In summary this means: when using your framework i can almost have what i want, a universal string data type (USTRING defined as CWstr). And only in some special cases (as said above) i must implement a CBstr, which mimics a BSTR, which is the required string data type for COM. If someone doesn´t want to use your framework in my IDE, i will supply a wide string data type (a clone of your CWstr) and some functions for string manipulation. In this case COM (and all other functionality of your frame work) is not available, and a decision between CBstr and CWstr is immaterial and pointless, because there is no use for CBstr, in fact there is no CBstr at all - so USTRING (= CWstr) can be used universally.


Do you agree?


JK

Offline José Roca

  • Administrator
  • Hero Member
  • *****
  • Posts: 2456
    • José Roca Software
Re: FreeBASIC CWstr
« Reply #92 on: May 29, 2018, 12:23:04 AM »
It is mandatory for parameters. For strings returned as the result of a function, you can assign it to a CBSTR, CWSTR, CVAR, STRING, WSTRING or even ignore it. The returned CBSTR is temporary and destroys itself.

If somebody does not want to use my framework, it will be his loss, not mine. I'm providing with it the functionality available in PowerBasic that is missing in FreeBasic and much more, although, of course, with a different syntax and programming style.

A SDK programmer should not have many problems to use my framework, but unfortunately the PBer's have been spoiled by DDT. Very few, if any, will use CWindow directly. Instead they will use a tool like the Visual Designer in which Paul Squires is working. The generated code will use CWindow and other wrappers internally, but for the custom code they will use the OOP classes in which Paul is also working. Millions of programmers have been spoiled by Visual Basic.


Offline Juergen Kuehlwein

  • Jr. Member
  • **
  • Posts: 54
Re: FreeBASIC CWstr
« Reply #93 on: May 29, 2018, 11:55:00 AM »
Quote
For strings returned as the result of a function, you can assign it to a CBSTR, CWSTR, CVAR, STRING, WSTRING or even ignore it. The returned CBSTR is temporary and destroys itself.


...even better! So the only place, where CBstr.vptr is mandatory in your framework, is an IN/OUT parameter in a COM method or property.



Quote
If somebody does not want to use my framework, it will be his loss, not mine.


i absolutely agree!



The Visual Designer in my IDE produces pure SDK code without any wrappers (it already does in PowerBASIC and it will do in FreeBASIC). In fact i´ve never understood, what´s the benefit of learning wrappers compared to learning the fundamentals, which can be re-used in almost every programming language for Windows. DDT and Visual Basic were attempts to make things easier (a marketing instrument) for beginners and professionals, but i agree, while maybe easier in the beginning both don´t make it easier in the long run, and both kept/keep people away from learning the fundamentals of the Windows API. I think we share the same point of view here.


Did you find any more problems in the code i posted (fb_str.inc, when USTRING is defined as CWstr)


JK

Offline José Roca

  • Administrator
  • Hero Member
  • *****
  • Posts: 2456
    • José Roca Software
Re: FreeBASIC CWstr
« Reply #94 on: May 29, 2018, 01:26:46 PM »
> ...even better! So the only place, where CBstr.vptr is mandatory in your framework, is an IN/OUT parameter in a COM method or property.

Only for OUT parameters. For IN/OUT parameters not (I mentioned it previously by mistake, sorry).

The reason is to avoid memory leaks. The COM rules are strict. When we pass a BSTR pointer to a COM method with an IN/OUT parameter, the COM method reads the content of the passed BSTR, does what it needs to do, frees the passed BSTR and returns a new allocated BSTR. When we pass it to an OUT parameter, it simply returns a pointer to a new allocated BSTR. Therefore, if we pass a BSTR that has contents, it won't we freed and we will have a memory leak. What the .vptr method does is to free the BSTR before pasing the pointer. The alternative is to clear the CBSTR before passing it.

> Did you find any more problems in the code i posted (fb_str.inc, when USTRING is defined as CWstr)

The fundamental flaw was to define it as CBSTR and then use it with a function designed to work with a CWSTR. CBSTR uses attaching instead of copying whenever possible for speed and for ease of use. If it is attached, the BSTR will we freed when the CBSTR is destroyed. If it is copied, you are responsible of freeing the original BSTR.

> I think we share the same point of view here.

If nobody did learn how to use the API, there won't be tools and frameworks available. Even the Windows API is a framework. My framework simply helps to do some things more easily. Instead of using CWSTR, you can work allocating and freeing your own buffers and manipulate them using pointers, but this is very hard.

When a SDK programmer tries to use a new compiler, as we are doing with FreeBasic, all he needs is to learn the intrinsics of the language, but DDTers will ask "What is the equivalent of CONTROL SET TEXT?," "What is the equivalent of CONTROL ADD LISTBOX?," etc. Excepting Paul, that has used it to write his editor, nobody has helped me to debug the framework. Everybody is lurking and waiting for the upcoming visual designer.

Anyway, I believe that almost all the DDTer's will continue to use PB for ever. Therefore, my efforts are directed to extend FreeBasic, not to attract DDTers.
« Last Edit: May 29, 2018, 03:42:21 PM by José Roca »