Gord P

Are  you talking about changing the default name of Button1 for example to btnOpen or something?  If so, I have never seen any guidelines for C++.   I have seen a bunch of code written with a three letter lowercase prefix of the control such as the btnOpen one I just mentioned.  I have seen mnuOpen for menu item, dlgOpen for dialog, actOpen for actions etc.  I have my own system which is different.  I think the main thing is being consistent and something you can search easy enough.  Or perhaps someone will point you to some standard somewhere.

18 hours ago, Ian Branch said:

I had a play with the Delphi Style Designer but it seems the colors are defined in a bitmap or similar file and I couldn't figure out how to change them. 

Yeah, it isn't intuitive or easy.  I was hoping they would eventually massively improve it.  Going through Ray's video really helps though.

18 hours ago, Ian Branch said:

Resolved.  It turns out that Aqua Light Slate is the one that I needed/wanted all along.

Glad you got what you needed.

A simple way to do that would be to add the Onyx Blue style to your project.  Then set the StyleName property *of the button* to Onyx Blue.  

Otherwise if you want more control over the exact color, you will probably have to use the Bitmap Style Designer.  Ray Konopka has an excellent video on YouTube on how to use it.  

If you don't want to do either of those, you might be able to use the Image and HotImage properties.  I have not gone that route, so I don't know if it works.  You would probably have to deselect seClient item in that case I would guess.

edit: in my original reply, I forgot the words "of the button" in the sentence above, which is critical.

After watching the latest Webinar on C++Builder by David Millington, I would say that the answer to my question is: Extremely low to nil. Although he did not explicitly say it.  

He talks about 32 bits at around the 55 min mark.

12 hours ago, hansw said:

One major drawback is the bad debugger of the 32-bit Clang tool chain. Expect missing variables ...

Good to know.

19 hours ago, Remy Lebeau said:

I don't see why. It's still clang, just a newer version with a higher language compliance.

I don't have any basis for my pessimism other than my experience with these kinds of things.

12 hours ago, Roger Cigol said:

I've brought a few "Classic" 32 bit VCL apps over to "Clang32". Most of the issues are related to poor code by me

Oh I definitely expect that to be the case for me.

Yes I am aware.  But when I looked at switching over to Clang from the Classic compiler it appeared that there would be a lot of changes to my code that I would have to make so I put if off.  You are right in that I could start the transition now with the old Clang but I am guessing (perhaps incorrectly) that there will be issues switching from the old Clang tool chain to the new one.  So I would rather just go to the new one and skip all that.  Plus for some reason, Code Completion doesn't work for me when using the old Clang compiler (11.3).  

On 10/29/2024 at 11:53 PM, Remy Lebeau said:

But, after it has matured a little bit, I'm sure they will update the 32bit compiler too, as 32bit development is still popular.

That's what I am hoping for.  But it would be nice to hear it from Embarcadero.  I wish they would go back to giving road maps - even with all the disclaimers. At least you get a bit of an idea of what they are thinking. 

Thanks for your thoughts. 

I would like to move away from the Classic compiler to the Clang compiler.  My project that I would like to do that with is large enough than when I looked at making the move a while ago there appeared to be a lot that I was going to have to change so I continued on the Classic compiler.  With the new Clang based c++ tool chain, making the move is more enticing.  However, to use the new tool chain there are two transitions at the same time I have to make.  One is to Clang and the other is 64 bits.  Since 64 bits isn’t crucial for the program, I would like make the transition to the new Clang toolchain in 32 bits.  Once the bugs have been worked out.  Then migrate it over to 64 bits.

Anyone hear anything on how likely that is?

I put in a feature request for it. RSS-2237

9 hours ago, Skrim said:

Is the first code line unnecessary?

I sure don't think so.  Assuming something is initialized is a bit dangerous IMO.  

Was the chart dropped on the form at design time, or was it created at run time?  If it was the former, I would be curious as to whether the issue exists if it gets created by code.  I am guessing not, but don't know.

I have had problems with TCharts that were placed at design time when moving from one version of Rad Studio to another because they use the old TChart files/headers and it screws things up.  

4 hours ago, Anders Melander said:

Btw, you should probably check out Agner Fog's vector library.

4 hours ago, Anders Melander said:

Here's an implementation:

https://github.com/lattera/glibc/blob/master/sysdeps/ieee754/dbl-64/e_pow.c

Thanks Anders, I'll check them out.

The pow(x, y) function is a bit of a bottleneck for me.  My exponents have to be doubles so I can't trade it out for multiplication routines.  After searching around, I see that this is a common issue in c++ and there is no simple fix.  I'm just curious if others had come across something to help speed things up.  Accuracy is an issue for me, so approximate solutions aren't appropriate.

1 hour ago, ConstantGardener said:

I think the onShow is also triggert if you change the VCL.Skin in your program?

Good to know.  Thanks. 

3 hours ago, Uwe Raabe said:

Can you be more explicit, what these some things may be?

I was afraid someone might ask me to clarify  that so I went through some older code hoping to find comments I left behind in the constructor or the OnShow event that might have explained where I ran into problems previously.  Alas, my commenting skills are gradually getting better, but started from a weak place.  

I *think* I ran into issues with either (or both) some UI stuff that wasn't created yet for some reason and/or calling a function.  I could totally be wrong here, but I just remember having some issues at some point a while back.  I suppose the thing to do, would be to try it in the constructor again and see if anything arises during the build because for sure the constructor only gets called once.

Thanks. (I don't have Delphi, but I got the gist from the code).  I guess I should have been more explicit.  The main form will not be programmatically hidden (i.e. the main form's Visible property will not be set to false, and its Hide() method will not be called).  I was just wondering if something in Windows could trigger an OnShow event even if I don't trigger one intentionally myself.  Simply minimizing and restoring doesn't trigger it.  I don't know if there is something else that might.  I don't think so, but was just wondering. 

I guess I have always assumed that is the case and code accordingly.  I made an extremely simple program and couldn't get the event to fire a second time, so it seems right but may not have captured all scenarios.  The constructor for sure only gets called once, but some things are not accessible at the time the constructor is called if I recall correctly.

I am kind of surprised that being able to VOTE on a request is not a request.  I thought I came across a post where someone said they put it in as a feature request, but I couldn't see it.  Perhaps it is one of those that went in as private instead of public.

Thanks but actually my gripe was broader.  I was unable to see any requests period.  It had been over a week since I signed up to the site (again) but I can now see all requests, including this one.

On 10/4/2024 at 8:54 AM, Roger Cigol said:

I now do have access to the RSS and have updated the posting thread with my confirmation of the issue.

Must be nice.  I still don't have access to other people's reports.

Okay, it sounds like I am not missing an obvious way to do it in the IDE then.  Thanks for the comments.

When I am looking at the code, I would rather have the Structure pane use the entire left side.  I don't need to see the Object Inspector.  But when I click on the Design tab, I would like it to appear again.  Is this possible without doing it manually everytime?

Now having said that, I just came across a reason why you would want to access the item instead of changing the Action itself.  For instance, if you wanted to change the caption of the menu item but you don't want the Action caption changed (say because a different control needs to have the original caption).  In this case, accessing the item itself is necessary.  This is doable at design time but I can't figure out how to do it at runtime.  Anyone have any ideas?

edit:  Okay I finally figured it out.  I was so close.  I needed to dynamic_cast it.  The correct line is

    dynamic_cast<TActionClientItem*>(ActionMainMenuBar1->ActionControls[3]->ActionClient->Items->Items[2])->Caption = "Finally!!!";   // or ->Visible = false;
 

I ended up doing what I mentioned in the edit above.  That is, created an action for the separator (changing the caption to "-") and toggled the action.  It is a simple enough solution. 

I have a separator which is the third sub item of the fourth menu item in a ActionMainMenuBar.  Because it is a separator there is no action associated with it.  

I have tried different routes but I am unable to access the Visible property of the item which is available in the Object Inspector at design time.

ActionMainMenuBar1->ActionControls[3] gets me to the fourth menu item but I am unable to drill down.

I tried ActionMainMenuBar1->ActionControls[3]->ActionClient->Items->Items[2] but could not access the visible property.

ChatGPT and CoPilot kept providing the same error proned code.

What is the correct way to do this?

(edit: I suppose I could assign an action to the separator and set the Visible property of the action to false, but there must be a proper way to access the item's Visible property without creating an action)

I got the same question.  But I didn't think of your answer.  That's funny.