In my BApplication object, before creating any window etc., I test for some things and pop up a BAlert. Only that what’s shown isn’t the usual nice alert with a grey stripe and icon at the left, but this thing:
(Plus the normal window border, but the Screenshot app refuses to capture it…)
It’s perfectly working, just looks crippled.
I’m at a loss. I’ve moved all the code from the BApplication constructor into ReadyToRun(), hoping that would help. It doesn’t. The code looks to me like a correct, ordinary BAlert:
void
App::ShowAlert(BString text)
{
BAlert* alert = new BAlert("Attention", text,
B_TRANSLATE("Cancel"), B_TRANSLATE("Open ledger"), B_TRANSLATE("Create new ledger"),
B_WIDTH_AS_USUAL, B_OFFSET_SPACING, B_INFO_ALERT);
alert->SetShortcut(0, B_ESCAPE);
switch (alert->Go()) {
case 0:
{
PostMessage(B_QUIT_REQUESTED);
} break;
//... and so on...
I just did a small test with a rudimentary BApplication object and copied your code into ReadyToRun(), only removing the B_TRANSLATE’s and calling the code directly from ReadyToRun() instead of the ShowAlert() function.
Looks like this (as expected)
The B_TRANSLATE() calls shouldn’t be the culprit, neither the ShowAlert function. Nevertheless, do you have the complete code online somewhere , for me to download and test?
My tests where done on a 64bit R1beta4 system (hrev56578+97).
Alert from the ledger branch of CapitalBe (had to remove a few isDark() calls because it’s not available on beta4:)
Alert from my test app, but this time with the original message copied from CapitalBe (again without B_TRANSLATE):
Not really a solution in sight but at least we know that the problem also appears on Beta4, and it doesn`t seem to have anything to do with the length or content of the alert message (which I began to suspect).
That’s it for now, I’ll take an in-depth look at the BAlert code later, maybe there are some conditions under which the icon is not displayed.
Yep, that was to be expected. At least we don’t have different behaviour between nightly and beta4 in this issue
I did a few more experiments and found a few interesting things. Not a real solution yet but maybe a pointer (no pun intended ) to what the problem might be.
I got the icon to display in CapitalBe (not entirely correctly but at least visible) if I either omit the B_OFFSET_SPACING flag like here:
or if I shorten at least one of the button labels on the 2nd or 3rd button which looks like this:
This simply seems to have to do with the available horizontal space on the alert window because that space always stays the same. Well not exactly as the first 2 screenshots show, but within certain limits.
So far so bad, now comes the confusing part. In my little test app, BAlert behaves differently, as can be seen in this screenshot with a ridiculously long button label and B_OFFSET_SPACING enabled.
No matter how much space is needed, the horizontal size of the alert just increases. I have no idea why this happens here but not in CapitalBe. I’ve looked at the constructor and ReadyToRun() implementations, nothing suspicous there. I’ve even disable the rdef definition in the Makefile to see if it makes any difference. It does not.
Next step: looking at the BAlert Source Code (especially at the layouting part) and trying to find out why the layout behaves differently in these two applications even though the BAlert is called with exactly the same code.
Btw: The normal border is there in all cases where the icon is present. That was only the screenshot application that cut away the border
It looks like CapitalBe includes some alert code in DAlert.cpp and DAlert.h. these could conflict with BAlert from libbe.
Maybe try to use DAlert instead of BAlert first.
DAlert works (after a quick edit, as it normally tries to center itself into the calling BWindow, which we don’t have when calling from the BApplication).
I actually want to do away with these DAlerts some time and use normal BAlerts. Haven’t looked into that yet…
Anyway, I don’t understand why the presence of DAlert spoils using a BAlert. I once tried to have a BAlert in the MainWindow code - which already uses DAlerts - but it refused to compile with a “BAlert not defined” or something, even though I explicitely included <Alert.h>…
DAlert.h uses #define _ALERT_H as an include guard, which is the same as Alert.h. So, after one is included, you can’t use the other. It should not use a name starting with an _, that’s reserved for the OS (by the C and C++ standards). Usually in my code I tend to replace these #ifndef/#define/#endif guards in header files by a simpler #pragma once. Then you don’t have to worry that someone may use the same name as you.
But the problems don’t stop there. It also redefined some enums (alert_type and button_spacing) that should be defined by the original Alert.h. I think they have the same values, so this should work. But if we look at the cpp file, it also redefined internal classes like TAlertView: CapitalBe/src/DAlert.cpp at ledgers · humdingerb/CapitalBe · GitHub
So, you are not using the TAlertView from Haiku, but the redefined one from DAlert. Except you call BAlert code from libbe.so, which has no idea about it, and uses code from libbe.so on it. Then everything is mixed up.
Removing DAlert seems the safest fix, but until you do that, maybe you an get away with renaming your TAlertView (to DAlertView, for consistency with the other classes in there?) to avoid the conflict.
Is this a symbol we are exporting for ABI compatibility with BeOS or something like that? Otherwise we could fix this on the Haiku side by stuffing TAlertView into BPrivate (or using an anonymous namespace even.)
I’ll remove the DAlert eventually, though I first have to look why it was used in the first place…
For now, @korli was so kind of fixing the conflicts with this commit that moves DAlert into the CapitalBe namespace. Though, as I’m still using DAlerts only, I haven’t tested the fix.
