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.

Yeah, it isn't intuitive or easy. I was hoping they would eventually massively improve it. Going through Ray's video really helps though. 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.

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

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.

Good to know.

I don't have any basis for my pessimism other than my experience with these kinds of things. 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). 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 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.

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.

Thanks Anders, I'll check them out.

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.

Good to know. Thanks.

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 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.

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

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?

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

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)

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 got the same question. But I didn't think of your answer. That's funny.