I would like to declare a TBitmap Globally.
I tried as follows:
Locally within a method, this works fine
std::auto_ptr<Graphics::TBitmap> RenderGraphic(new Graphics::TBitmap());
OR
Graphics::TBitmap * RenderGraphic = new Graphics::TBitmap;
So to declare it globally I tried this in the header file
Graphics::TBitmap *RenderGraphic;
And this in the constructor
__fastcall TShipGraphic::TShipGraphic(TComponent* Owner)
: TForm(Owner)
{
Graphics::TBitmap * RenderGraphic = new Graphics::TBitmap;
}
Which compiles fine but when running, throws an access violation exception at the first occurrence of
RenderGraphic->Canvas->Pen->Color = clBlack;
Please advise, tks in advance.
The reference source I was using is C++ Builder Graphics Introduction
which suggested the declaration in the constructor
You need to implement a singleton. Consider read-only case (bitmap is created once, no setter function).
In MyGraphics.h define accessor function
#include <vcl.h>
TBitmap* GetRenderGraphic();
Implementation in MyGraphics.cpp
static std::unique_ptr<TBitmap> renderGraphic(new TBitmap());
TBitmap* GetRenderGraphic()
{
return renderGraphic.get();
}
Use it (required including of MyGraphics.h)
GetRenderGraphic()->Canvas->Pen->Color = clBlack;
Related
Is there a reference to a class property in C++Builder, analogous to a regular reference in C++? To understand what I mean, I will give the code (so far this is my solution to the problem):
void change(TControl* object) {
struct TAccessor : TControl { __property Text; };
static_cast<TAccessor*>(object)->Text = L"some text";
}
This function allows you to change the Text property of any object inherited from TControl.
But maybe there is a more elegant solution to this problem?
Your approach will update the Text of any TControl, even if it doesn't actually expose access to Text (which is declared protected in TControl itself, derived classes decide whether to promote it to public/__published as needed).
To account for that fact, you would have to use RTTI to discover if Text is accessible or not. You can also use RTTI to set the property value, without resorting to the Accessor trick.
For example, old-style RTTI (via the <TypInfo.hpp> header) works only with __published properties, nothing else, eg:
#include <TypInfo.hpp>
void change(TControl* object) {
if (IsPublishedProp(object, _D("Text"))
SetStrProp(object, _D("Text"), _D("some text"));
}
Alternatively:
#include <TypInfo.hpp>
void change(TControl* object) {
PPropInfo prop = GetPropInfo(object, _D("Text"), TTypeKinds() << tkUString);
if (prop)
SetStrProp(object, prop, _D("some text"));
}
Whereas newer-style Extended RTTI (via the <Rtti.hpp> header) supports fields, methods, and properties, and all the supported member visibilities, eg:
#include <Rtti.hpp>
typedef Set<TMemberVisibility, mvPrivate, mvPublished> TMemberVisibilitySet;
void change(TControl* object) {
static const TMemberVisibilitySet WantedVisibilities = TMemberVisibilitySet() << mvPublic << mvPublished;
TRttiContext ctx;
TRttiType *type = ctx.GetType(object->ClassType());
TRttiProperty* prop = type->GetProperty(_D("Text"));
if ((prop) && (WantedVisibilities.Contains(prop->Visibility)) && (prop->IsWritable))
prop->SetValue(object, _D("some text"));
}
To send data to multiple clients I create a TIdThreadSafeStringList in OnConnect and assign it to AContext->Data like so
AContext->Data = new TIdThreadSafeStringList
When the client disconnects, its stringlist is deleted in OnDisconnect like so
delete AContext->Data
However this results in an AV. If I zero the parameter, like so
delete AContext->Data
AContext->Data = NULL
the AV goes away. Is there some auto cleanup I'm not aware of?
Using C++ Builder 10.2.3.
Is there some auto cleanup I'm not aware of?
Yes. TIdContext derives from TIdTask, which owns the Data property. The TIdTask destructor is called after the OnDisconnect event and will free the Data object if it is not NULL.
Another (preferred) way to handle this situation is to instead derive a new class from TIdServerContext and add your TIdThreadSafeStringList to that class (and any other per-client custom functionality you want), eg:
class TMyContext : public TIdServerContext
{
public:
TIdThreadSafeStringList *MyList;
__fastcall TMyContext(TIdTCPConnection *AConnection, TIdYarn *AYarn, TIdContextThreadList *AList = NULL)
: TIdServerContext(AConnection, AYarn, AList)
{
MyList = new TIdThreadSafeStringList;
}
__fastcall ~TMyContext()
{
delete MyList;
}
//...
};
Then assign your class type to the server's ContextClass property at runtime before activating the server, eg:
__fastcall TMyForm::TMyForm(TComponent *Owner)
: TForm(Owner)
{
IdTCPServer1->ContextClass = __classid(TMyContext);
//...
}
Then, you can simply type-cast any TIdContext* pointer belonging to the server to your class type in order to access the TIdThreadSafeStringList (or other functionality):
static_cast<TMyContext*>(SomeIdContext)->MyList->...
This way, you can ignore the TIdContext::Data property altogether, or use it for other purposes, if desired.
I am still using deprecated TServerSocket component.
I would like to bind TServerSocket to a specific IP. This question has been previously asked before for Delphi in this site: How to Bind a TServerSocket to a specific IP address
However I couldn't make it work in C++ Builder.
My code is:
class ServerWrapper : private TServerSocket {
public:
ServerWrapper();
private:
};
ServerWrapper::ServerWrapper()
: TServerSocket (0)
{
//---
}
ServerWrapper* pServer =0;
//...
//..
//.
// And in a function:
pServer = new ServerWrapper;
pServer->Address = "192.168.0.1" ;
pServer->Active = true;
However it doesn't compile.
It says:
E2247 'TAbstractSocket::Address' is not accessible
I am using C++ Builder 10.1.2 Berlin by the way.
It doesn't work because you did not translate the Delphi code to C++ correctly.
For one thing, you are using private inheritance instead of public inheritance. So all public and protected members inherited from TServerSocket will be private in ServerWrapper. Delphi has no notion of protected/private inheritance, only public inheritance.
But more importantly, Delphi has a notion of implicit friendship. Within a unit, all classes have full access to private/protected members of other classes that are declared in the same unit. That includes inherited protected members. The Delphi example in the other question takes advantage of that feature, by declaring a local helper class to implicitly gain public access to the Address property for the unit that declares the helper.
But C++ has no notion of implicit friendship. To translate the Delphi example to C++, you have to explicitly promote access to the protected Address property.
A literal translation of the Delphi code would look like this in C++:
class TServerSocketAccess : public TServerSocket
{
public:
__property Address;
// or:
// using TServerSocket::Address;
};
((TServerSocketAccess*)ServerSocket1)->Address = "192.168.0.1";
ServerSocket1->Active = true;
Applied to your ServerWrapper class, it would look like this:
class ServerWrapper : public TServerSocket
{
public:
ServerWrapper();
__property Address;
// or:
// using TServerSocket::Address;
};
ServerWrapper::ServerWrapper()
: TServerSocket (0)
{
//---
}
ServerWrapper* pServer = 0;
//...
pServer = new ServerWrapper;
pServer->Address = "192.168.0.1";
pServer->Active = true;
I have a static library in C++, and now I want to use this library in my new Swift project. I found that I couldn't use C++ class directly in Swift project, so I have to wrapper this library in OC. Then I have some problem wrapping this:
//AbstractClassA.h
#include <string>
class AbstractClassA {
public:
virtual string getString() = 0;
virtual int getInt() = 0;
virtual ~AbstractClassA() {};
};
//AbstractClassB.h
class AbstractClassB {
public:
virtual void function(int a) = 0;
virtual ~AbstractClassB() {};
};
//ChildA.h
#include "AbstractClassA.h"
#include "AbstractClassB.h"
class ChildA : public AbstractClassA
{
public:
ChildA(int a = 640);
ChildA( AbstractClassB* classb, int a = 640);
virtual ~ChildA();
string getString();
int getInt();
protected:
int a;
string b;
};
How to wrapper these classes in OC? Thanks for any help!
You create an Objective-C++ class that wraps the C++ class. The header file must not contain any C++ features; the file with the implementation must end in .mm to tell Xcode to use the Objective-C++ compiler, not Objective-C.
In the .h file, you'd have an interface for class ChildAWrapper, methods init, initWithInt:, initWithClassB:, initWithClassB:Int: and readonly properties stringValue and intValue.
In the .mm file, you'd have an instance variable of type ChildA*. The init methods create a ChildA object. dealloc deletes it. You implement the properties by calling the methods of the ChildA object, converting the std::string to an NSString*.
Same for ClassB with an Objective-C class ClassBWrapper. There you want a readonly property void* wrappedClass returning a pointer to the the ClassB object, converted to void*, because ChildAWrapper will need that.
I'm trying to use C++ Template 'mixins' to create some new VCL components with shared additional functionality. Example...
template <class T> class Mixin : public T
{
private:
typedef T inherited;
// ...additional methods
public:
Mixin(TComponent *owner) : inherited(owner)
{
// .. do stuff here
};
};
Used like this:
class MyLabel : public Mixin<TLabel>
{
....
}
class MyEdit : public Mixin<TEdit>
{
....
}
Now, everything compiles fine, and the mixin stuff seems to work - until I try and save the component to a stream using TStream->WriteComponent, where the inherited properties (eg TLabel.Width/Height/etc.) don't get written. This is even with a 'null' mixin like the one shown above.
My code works fine when just deriving classes directly from TForm, TEdit, etc - and the class is correctly registered with the streaming system.
The quick/simple answer is: no; when dealing with a template, the compiler won't generate the proper descriptors to make streaming working. However, since this has come up before, I peeked under the cover to find out what's missing. And what I found is that it's almost there. So here's a little more information.
Upfront the compiler will never treat a template-based type as a Delphi. For example, do something like this:
void testing()
{
__classid(Mixin<Stdctrls::TLabel>); // Error Here
}
... and you'll see the error
"Error E2242 test.cpp 53: __classid requires Delphi style class type (i.e. class marked __declspec(delphiclass) or derived from System::TObject) in function testing()"
This basically says the compiler does not consider this type/class as compatible with Delphi-classes [i.e. those that derive from TObject]. Internally there's just a flag on the symbol that says whether the type is delphi-compatible or not. And I noticed that I could trick the compiler into marking the type as delphi-style if I forced it to walk up the hierarchy.. which is something it has to do if I create an instance of the object. So, with this hack the error goes away:
void testing()
{
typedef Mixin<Stdctrls::TLabel> __ttype;
std::auto_ptr<__ttype> c2(new __ttype(0));
__classid(Mixin<Stdctrls::TLabel>); // No more errors here
}
But much nicer was actually to use the __declspec(delphiclass) directly on the template, as in:
template <class T>
class __declspec(delphiclass) Mixin : public T {
private:
int i;
typedef T inherited;
public:
__fastcall Mixin(TComponent *owner) : inherited(owner) {};
};
So now that the compiler treats the type as a delphi-style class without hacks, I peeked a little more and found the issue you're probably running into: Delphi classes have the TTypeData.PropCount field - http://docwiki.embarcadero.com/VCL/en/TypInfo.TTypeData - which is a sum of the class' properties, including those of its base classes. Due to the way the various pieces of information are computed, the compiler writes out a '0' for that field when a template is involved:(
You can see this by printing out the PropCount, as in:
#include <Stdctrls.hpp>
#include <cstdio>
#include <memory>
#include <utilcls.h>
class TCppComp : public Classes::TComponent {
int i;
public:
__fastcall TCppComp(TComponent* owner): Classes::TComponent(owner) {};
__published:
__property int AAAA = {read=i, write=i};
};
template <class T>
class __declspec(delphiclass) Mixin : public T {
private:
int i;
typedef T inherited;
public:
__fastcall Mixin(TComponent *owner) : inherited(owner) {};
};
typedef Mixin<TCppComp> TMixinComp;
void showProps(TClass meta) {
PTypeInfo pInfo = PTypeInfo(meta->ClassInfo());
int Count = GetPropList(pInfo, tkAny, NULL);
TAPtr<PPropInfo> List(new PPropInfo[Count]);
std::printf("Class: %s - Total Props:%d\n",
AnsiString(pInfo->Name).c_str(), Count);
GetPropList(pInfo, tkAny, *(reinterpret_cast<PPropList*>(&List)));
for (int i = 0; i < Count; i++) {
AnsiString propName(List[i]->Name);
std::printf("\t%s\n", propName.c_str());
}
}
void test() {
showProps(__classid(TCppComp));
showProps(__classid(TMixinComp));
}
int main() {
test();
return 0;
}
When run the above prints:
Class: TCppComp - Total Props:3
AAAA
Name
Tag
Class: #%Mixin$8TCppComp% - Total Props:0
IOW, Mixin shows up with '0' published properties while its base type has 3:(
I suspect the streaming system relies on this count and that's why inherited properties are not being written out in your setup.
I considered tweaking the generated descriptors at runtime but since we write them to _TEXT it's bound to trigger DEP.
I'll look at the logic that computes the PropCount to see if there's some way to get it to compute the correct number. If time allows, please do open a QC for this: now that I've peek underneath, I believe it would not require much effort to get this working as expected.
Cheers,
Bruneau
PS: In my sample I even had the Mixin publish a property and the compiler generated the correct descriptor for that property; however, the total count was still zero.