CyberPeter

I needed to convert the class names to a TStyleHookClass, which is a TClass, by using __classid() Vcl::Themes::TStyleManager::Engine->RegisterStyleHook(__classid(TATBinHex), __classid(TScrollingStyleHook)) ;

Right. The thing is, Builder doesn't like my code and I don't understand why ? Vcl::Themes::TStyleManager::Engine->RegisterStyleHook(TATBinHex, TScrollingStyleHook) ; [C++ Error] main.cpp(30, 54): 'TATBinHex' does not refer to a value [C++ Error] main.cpp(30, 65): 'TScrollingStyleHook' does not refer to a value I thought the pas file needed to change but if you say that is not the case then I'm not sure what to do with this. Obviously I'm not fully up to speed on Styles in custom components. The Embarcadero documentation tends to be horrible for c++ Builder users.

It compiles fine but for whatever strange reason I can't instantiate the TBCHexEditor class ? The error suggests pure virtual functions ? In a component class ? I don't think so. That one has got me puzzled. There is also a TBCHexEditorEx class that I haven't tried yet. The total absence of any documentation is annoying. No idea what the difference between the two versions is ? Meanwhile my day (and concentration) is almost at an end.

Oh .. I notice he has something recent as well: https://github.com/zhugecaomao/BCHexEditor Will have a look

I'm convinced Delphi would run into the same problems. The code is simply too old (2007) and hence dates back from before proper Unicode implementation etc. For a Delphi developer it's probably not that difficult to update the code.

Too many errors when trying to build with C++ Builder 11.3 Not knowing much about Delphi syntax this currently is too much an uphill battle, especially because the result (look / feel) is a big unknown.

This is going to be harder for me, not being versed in Delphi. I looked it up and it appears TATBinHex needs to inherit from TStyleHook https://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.Themes.TStyleHook I'm already glad I managed to 'fix' the *.pas files enough so that I could build them into a lib/a file 🙂 Could you share the changed *.pas file where this change is made ? Things are looking better with the suggested color changes. I just wish the binary selection was contiguous, not be per byte/cell.

I wish the author had included a few screenshots. I'll have a look, thanks for the suggestion.

While very impressive, it seems a bit excessive for my needs (assuming I'd be allowed to integrate that in another app)

Oh, thanks for that !! I'll check it out.

Well, I can get it to work ! Of course with Styles it's going to stick out like a sore thumb And I'm not wild about the selection functionality: But it's certainly a candidate. I'd have to inherit from TStream then to integrate it in a project where data is read into a buffer. If there are other candidates, I'd like to know, I'm not 'in love' (yet) with this one 😉

Yes, it looks that way. Playing with it now. I thought it only supported it in components that need to be installed.

Thank you for the suggestion KodeZwerg. I actually did run into this one, a long time ago, so I didn't really consider it this time, during my search. But I should. I'll look into it shortly. I also found a conversion of this particular component into c++ via an automated tool. I tried it in CB2009 and while it compiled, it did not work properly. I will look into it again however. It's dated, so I hope it compiles, not being very Delphi savvy (if at all) and hence clumsy at trying to 'fix' it. I do seem to recall the hex view selection not being smooth across bytes, rather one (or more) individual bytes (cells) are selected with space in between.

Hi, I have a C++ Builder 11.2 project that is compiled on a machine with 100% scale setting. I put in considerable work to make sure that dynamically resized objects (based on content, text etc) all scale properly between different dpi monitors etc. I'm now moving my project to a new main system with a bigger screen and I want to use the default 150% scale setting on this machine I'm still not 100% on the whole scaling thing. PixelsPerInch return confusing values sometimes and I'm also not fully sure what is stored during design etc. My question, if/when I rebuild this project 'as is' on the new system, will it still look the same when deployed on a 100% scaled system etc ? Do I need to make changes ? Re-save all the forms ? Any input before I start messing things up is greatly appreciated. Peter

Of course, and indeed I do that all the time as well. What I meant was I may want to edit a form and leave the rest unchanged. Then I have one form saved with dpi 150% and the other ones still with 100% .. I think Then I'd need to query the form to know with what dpi setting it was saved during design

Me too but it turns out I'm more comfortable with 150%. Not the youngest anymore, reading glasses and all that .. Sure, but what about the main form in an opened project ? Perhaps no changes were saved to file, but already changed in memory. Also, what if a form needs to be edited, yet all the other forms are still OK and should remain unchanged. I have some code that relies on the design dpi, currently hard coded, because I found no way to check the design time dpi per form.

Thanks for the heads-up I'm still on 11.1 I simply link in ics .lib and .a files, built with 11.1 Any idea if I should rebuild these libraries with 11.2 when I update my main project to 11.2 ?

I recently upgraded my old C++ Builder 2009 to C++ Builder 11. It was time .. and I wanted to make use of the new GUI improvements (Styles, Scaling, High DPI etc). GUI stuff in other words. To that end I spent a lot of money to get a license. Everything is relative, but to me this is the biggest investment in quite some time and the biggest software investment ever. I have always been happy with Builder 2009 and yes, there were some issues that I had to work around, but not too many. Since I have upgraded I have already reported close to 20 bugs. Never ever did I have to .. It's also making me nervous as to when these things will get fixed, if at all, as it impacts my work. The silver lining at least was that my bugs triggered interaction. I saw them being escalated to development or they were assigned to me again to provide more information. All that has stopped in the last few weeks. For all the last bugs there has been zero interaction. Nothing, as if nobody cares. The GUI work involves custom controls for which I need the help files, to be able to apply the Styles properly etc. In itself already poorly documented but for 3 weeks now docwiki has predominantly been unavailable. There are already other posts about that, so I won't get into the specifics of that, but it adds to what looks like a systemic failure. - Many bugs in the very features they're touting about and that convinced me to upgrade - Nothing appears to be done about it, nobody seems to care - Docwiki offline, nothing seems to be done about it, nobody (at embarcadero) seems to care The person most responsive in QA before and who has not responded anymore has a Ukrainian name. Perhaps coincidence, perhaps my paranoia but how exposed is Embarcadero development and support to Ukraine. Is this the reason for all the recent issues ? If so, communicating about it would at least renew confidence. All this nonsense would not be necessary if they would just COMMUNICATE about the issues (docwiki for instance). The silence only feeds the idea of a failing company or at least a failing product and I feel bad for having invested my time and money in this at this stage. My 'happy life' with Builder 2009, the type of work I'm doing with it and the low exposure to issues may have made me blind to something that is well known and has been happening for years ? I don't know ? Maybe I shouldn't worry because this is business as usual ? In which case I wish I had done my homework though.

And the morning brings clarity .. 🙂 Turns out I still had the form's 'TransparentColor' property set to 'true' (Left over from my first attempt, see start of conversation). I reset it to 'false' and now above code works beautifully. This window cannot be moved with the mouse. Frankly, I'm not sure what code or setting is responsible for this difference in behavior

I built and played a bit with your code Anders and it works nicely. Stubborn as I am I created a smaller class with only a splash, highly inspired by your code (also my old code so it seems, there is certainly overlap - but now I'm able to ignore a lot of old crap and rely on PNG). Sadly my today's implementation doesn't work fully. I must be missing something, but I cannot spot it. Perhaps it's obvious ? Anybody any idea as to why UpdateLayeredWindow() always fails with error 87 ( ERROR_INVALID_PARAMETER ). I can't seem to find where the problem lies //--------------------------------------------------------------------------- void __fastcall TForm1::Button3Click(TObject *Sender) { String ResourceName(L"SPLASH2") ; TSplashScreen *Splash = new TSplashScreen(3000, 100, ResourceName) ; Splash->Show() ; } //--------------------------------------------------------------------------- //--------------------------------------------------------------------------- __fastcall TSplashScreen::TSplashScreen(int TimeToDisplay, int Alpha, const String &ResourceName) : TForm((TComponent*)NULL), FBitmap(NULL), Alpha(Alpha) { Timer->Interval = TimeToDisplay ; Timer->Enabled = false ; // Set Layered if (SetWindowLong(Handle, GWL_EXSTYLE, (GetWindowLong(Handle, GWL_EXSTYLE) | WS_EX_LAYERED))) { // Background covers whole form ControlStyle << csOpaque ; // Create BitMap FBitmap = new TBitmap ; // Load the PNG from resource LoadPNG(ResourceName) ; // Resize form to fit bitmap ClientWidth = FBitmap->Width ; ClientHeight = FBitmap->Height ; } } //--------------------------------------------------------------------------- __fastcall TSplashScreen::~TSplashScreen() { delete FBitmap ; } //--------------------------------------------------------------------------- void __fastcall TSplashScreen::TimerTimer(TObject *Sender) { Timer->Enabled = false ; // This event only once Hide() ; Application->ProcessMessages() ; delete this ; // Self destruct when time is up } //--------------------------------------------------------------------------- void __fastcall TSplashScreen::FormShow(TObject *Sender) { Display(Alpha) ; if (Timer->Interval) Timer->Enabled = true ; } //--------------------------------------------------------------------------- void TSplashScreen::LoadPNG(const String &ResourceName) { TStream *Stream = NULL ; __try // Load PNG from resource (which must be added to the project) { wchar_t Type[] = L"PNG" ; Stream = new TResourceStream((NativeUInt)HInstance, ResourceName, Type) ; TPngImage *PNG = NULL ; __try { PNG = new TPngImage ; PNG->LoadFromStream(Stream) ; FBitmap->Assign(PNG) ; FBitmap->PixelFormat = pf32bit ; FBitmap->AlphaFormat = afPremultiplied ; } __finally { delete PNG ; } } __finally { delete Stream ; } } //--------------------------------------------------------------------------- void TSplashScreen::Display(int Alpha) { // Position bitmap on form POINT BitmapPos = {0, 0} ; SIZE BitmapSize = {FBitmap->Width, FBitmap->Height} ; // Setup alpha blending parameters BLENDFUNCTION BlendFunction ; BlendFunction.BlendOp = AC_SRC_OVER ; BlendFunction.BlendFlags = 0 ; BlendFunction.SourceConstantAlpha = Alpha ; // Transparency Value (255 is not transparent, 0 is fully transparent) BlendFunction.AlphaFormat = AC_SRC_ALPHA ; // Display if (!UpdateLayeredWindow(Handle, 0, NULL, &BitmapSize, FBitmap->Canvas->Handle, &BitmapPos, 0, &BlendFunction, ULW_ALPHA)) { DWORD Error = GetLastError() ; } Application->ProcessMessages() ; } //---------------------------------------------------------------------------

Oh cr@p, good point. Not doing that though 😉 Oh wow, thank you very much Anders. I'm not good with Delphi (at all), so I will need some time to digest this.

Sadly that's at an unholy hour for people in Australia, certainly for those with kids. (2:30 am in South Australia) I dread having to wait for an edited video on YouTube.

It would explain a lot. But they owe us transparency. It should be part of the 'contract' we entered when we paid the license fee. We're not a knitting group, we're all professionals trying to get our work done. We need to know what is happening (to some extent) and what is being done about it (to some extent) so that we can properly plan and communicate to our 'dependants' (customers, management, ..)

It's an absolute disgrace. They really don't care do they ? Plenty of bugs reported already on this issue in https://quality.embarcadero.com (also by me). They tend to get closed as 'resolved' and duplicate. Must be good for the stats. I don't know what's worse, not being able to fix something like this or totally ignoring the community and not communication about it at all.

Thank you Angus. I downloaded the overnight zip and built the run-time packages again. I did not bother with the design time packages this time as I don't need them anyway. All built OK and I could use the *.hpp files together with the *.obj / *.o files to get HttpCli to work in a 32 and 64 bit test app. I saw the exact same result as with previous overnight zip that I tried.