Shell_NotifyIcon NIF_INFO not showing icons - winapi

Im having issues with balloons firstly they refused to show at all but having found this thread:
Why aren't Shell_NotifyIcon balloon tips working?
then changing cbSize to 504 the balloons show but without icons in them, all the standard icons won't show nor will a custom icon, structure looks like this:
cbSize = 504
hWnd = HDL
uID = 10
uFlags = NIF_INFO
szInfo = sBody
uTimeout = 20000
szInfoTitle = sTitle
dwInfoFlags = NIIF_ERROR
does anyone know of a reason why the icons will fail? (Have tried all the structure sizes and uVersion in the various combinations)
Edit:
S.cbSize = 504;
S.hWnd = HDL;
S.uID = 101;
S.uFlags = NIF_MESSAGE + NIF_ICON + NIF_TIP;
S.uCallbackMessage = 0x4DE;
S.hIcon = iHDL;
S.szTip = sTooltip;
S.uVersion = 3;
S.dwInfoFlags = NIIF_NONE;
Shell32.Shell_NotifyIconA(NIM_ADD,S:GetPointer())
Shell32.Shell_NotifyIconA(NIM_SETVERSION,S:GetPointer())
That's used to create the tray icon and it does:
All the callback messages work with the change tooltip/change icon/set focus/delete tray icon functions also working as expected on XP and Win 8.1 all using cbSize = 504 and uVersion = 3 with Ansi NIM_SETVERSION and NOTIFYICONDATA, balloons will show its just no icons will show not even the default ones:
S.cbSize = 504;
S.hWnd = HDL
S.uID = 101
S.uFlags = NIF_INFO
S.szInfo = sBody
S.uTimeout = 20000
S.szInfoTitle = sTitle
S.dwInfoFlags = NIIF_ERROR
Shell32.Shell_NotifyIconA(NIM_MODIFY,S:GetPointer())
Using size of structure for cbSize works for everything but balloons, they wont even show, and that size reports as 688.

cbSize=504 is only meaningful if you are using the Ansi versions of Shell_NotifyIcon() and NOTIFYICONDATA, are using the XP (v3) version of NOTIFYICONDATA, and your compiler's alignment settings are actually aligning the NOTIFYICONDATA fields correctly so the XP fields line up to exactly 504 bytes. Without seeing your actual code, your compiler settings, or any context information at all, there is no way to troubleshoot your problem further.

Related

VB6 upon loading converts adodc to pictureBox

Setup windows 10 running and compiling vb6 for our product.
Haven't had issues until recently and my handling of git caused some errors so I had to reload things in from our original copy on another machine.
The issue lies within the form section of my project and I have finally discovered what is causing the issue.
The original issue was though I had the proper components and references loaded in and i could see it in my object browser it failed to use it and gave me the error: method or data member not found
After tons of searching I found out the it was converting
what was suppose to be an adodc into a picture box
Height = 375
Left = -63480
Top = 480
Visible = 0 'False
Width = 1200
_ExtentX = 2117
_ExtentY = 661
ConnectMode = 0
CursorLocation = 3
IsolationLevel = -1
ConnectionTimeout= 240
CommandTimeout = 240
CursorType = 2
LockType = 3
CommandType = 1
CursorOptions = 0
CacheSize = 50
MaxRecords = 0
BOFAction = 0
EOFAction = 0
ConnectStringType= 1
Appearance = 1
BackColor = -2147483643
ForeColor = -2147483640
Orientation = 0
Enabled = -1
Connect = ""
OLEDBString = ""
OLEDBFile = ""
DataSourceName = ""
OtherAttributes = ""
UserName = ""
Password = ""
RecordSource = $"frmDP.frx":0EAA
Caption = "Adodc1"
BeginProperty Font {0BE35203-8F91-11CE-9DE3-00AA004BB851}
Name = "MS Sans Serif"
Size = 8.25
Charset = 0
Weight = 400
Underline = 0 'False
Italic = 0 'False
Strikethrough = 0 'False
EndProperty
_Version = 393216
End
However when you open up the project it labels this as well as at least I've found ```TrueOleDBGrid80.TDBGrid````
to also be labeled and properties set as a pictureBox
I've verified i have the libraries on my machine and are registered.
I've made sure the components and references that are required to use these are also choosen and applied
Reference=*\G{6B263850-900B-11D0-9484-00A0C91110ED}#1.0#0#..\..\..\..\Windows\SysWow64\msstdfmt.dll#Microsoft Data Formatting Object Library 6.0 (SP4)
Reference=*\G{00000206-0000-0010-8000-00AA006D2EA4}#2.6#0#..\..\..\..\Program Files (x86)\Common Files\System\ado\msado26.tlb#Microsoft ActiveX Data Objects 2.6 Library
Reference=*\G{3D5C6BF0-69A3-11D0-B393-00A0C9055D8E}#1.0#0#..\..\..\..\Program Files (x86)\Common Files\designer\msderun.dll#Microsoft Data Environment Instance 1.0 (SP4)
Reference=*\G{420B2830-E718-11CF-893D-00A0C9054228}#1.0#0#..\..\..\..\Windows\SysWOW64\scrrun.dll#Microsoft Scripting Runtime
Reference=*\G{00025E01-0000-0000-C000-000000000046}#5.0#0#..\..\..\..\Program Files (x86)\Common Files\Microsoft Shared\DAO\dao360.dll#Microsoft DAO 3.6 Object Library
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0; mscomctl.ocx
Object={67397AA1-7FB1-11D0-B148-00A0C922E820}#6.0#0; MSADODC.OCX
Object={CDE57A40-8B86-11D0-B3C6-00A0C90AEA82}#1.0#0; msdatgrd.ocx
Object={C932BA88-4374-101B-A56C-00AA003668DC}#1.1#0; msmask32.ocx
Object={F9043C88-F6F2-101A-A3C9-08002B2F49FB}#1.2#0; ComDlg32.ocx
Object={3B7C8863-D78F-101B-B9B5-04021C009402}#1.2#0; richtx32.ocx
Object={248DD890-BB45-11CF-9ABC-0080C7E7B78D}#1.0#0; mswinsck.ocx
Object={86CF1D34-0C5F-11D2-A9FC-0000F8754DA1}#2.0#0; mscomct2.ocx
Object={BDC217C8-ED16-11CD-956C-0000C04E4C0A}#1.1#0; TABCTL32.ocx
Object={E7BC34A0-BA86-11CF-84B1-CBC2DA68BF6C}#1.0#0; ntsvc.ocx
Object={562E3E04-2C31-4ECE-83F4-4017EEE51D40}#8.0#0; todg8.ocx
I can manually recreate it though I did not make this myself and more so was put into this section and have had to dig a lot to understand a lot of these things.
The answer i am trying to find is why aren't these being created the way theyre coded to be created.
Or how can i convert these over and have vb6 fix it itself/

TGauge doesn't change value in runtime

At first, please bear with me, as I am quite new to the Delphi world. I am a former C++, C# and embedded developer.
I have Delphi 7 and Delphi RAD Studio 10.2 Starter on Windows 7 64-bit.
I have tried the TGauge component in both versions, as it is standard in Delphi (I think).
So, the issue is when I try to set the Progress property with a value at run-time, it doesn't reflect that on the GUI. But, if I set a value at design-time from the Object Inspector, it reflects the value as it should be, and the Gauge
paints the percentage correctly.
Steps to test this behavior:
Dragged and dropped the TGauge component from the "Samples" palette onto the Form.
I set MaxValue = 100 and MinValue = 0 in the Object Inspector.
I created a textbox (txtValue) on the Form.
I created a button (btnSetValueClick) on the Form and used this code:
procedure TMainForm.btnSetValueClick(Sender: TObject);
begin
Gauge1.Progress := StrToInt(txtValue.Text);
end;
So, I was expecting the Gauge would show the value entered, but it didn't.
When I debug the code, it hits btnSetValueClick() and sets the value inside.
What am I missing here?
EDIT: (This is the code in the form.)
object Gauge1: TGauge
Left = 53
Top = 81
Width = 191
Height = 113
ParentCustomHint = False
Color = clMenu
ForeColor = clRed
Font.Charset = DEFAULT_CHARSET
Font.Color = clBlack
Font.Height = -11
Font.Name = 'Default'
Font.Style = []
Kind = gkNeedle
ParentColor = False
ParentFont = False
Progress = 35
EDIT:
I have created a new project and started from scratch. I put the TGauge without changing any single properties of it. And it has started to work although I don't still see the difference can cause this behavior. At least this might give a clue this component can go wrong without an obvious reason, especially to beginners like me.
Please consider the case is as closed. Thank you.

Form property automatically changing on saving changes in VB6 (configured with VSS 2005)

I am facing below issue in VB6 :
When I checkout file file and check "Show differences" it is showing no difference (identical files) but when I save my changes without changing and form property and again check for differences in VSS , it is showing difference in few property.One of them is mentioned below.Kindly suggest.
Begin VB.Label CommStatus
BackColor = &H80000014&
BorderStyle = 1 'Fixed Single
BeginProperty Font
**Name = "Arial"** 'this property is changing
Size = 8.25
Charset = 204
Weight = 700
Underline = 0 'False
Italic = 0 'False
Strikethrough = 0 'False
EndProperty
ForeColor = &H000000C0&
Height = 375
Left = 240
TabIndex = 3
ToolTipText = "The most recently detected error"
Top = 360
Width = 7815
End
You can check attach image
After looking in to this, the reason for seems to be Windows zoom setting (100%,125% and 150%, control panel/Make text and other items larger or smaller). If the form is checked in to TFS/VSS/GIT in one zoom setting, and later edited in another, VB6 will change all kind of form properties to adjust for this. So this probably only happens in dev teams with 2+ users that happens to have different screen sizes and therefor different zoom settings.
Only way to avoid this is probably to all use the same zoom setting...

Photoshop javascript save error 8800

In my javascript, in Windows 7, Photoshop CS2 & Photoshop CS5, it throws an error:
Error 8800: General Photoshop error occurred. This functionality may not be available in this version of Photoshop.
- Could not save a copy as "C:...\wcb-010B-11Y.jpg" because the file could not be found.
Line: 458
-> docRef.saveAs( saveFile, jpgSaveOptions, true, Extension.LOWERCASE );
here is a summary of the code to save the image:
var selectedSaveDir = "~/Desktop/";
var sFileNamePreFix = "wcb-";
var docRef = app.activeDocument;
var docName = app.activeDocument.name;
var docNewName = docName.substr( 0, docName.length - 4 ); // strip file extension
var sNewDocName = sFileNamePreFix + docNewName + ".jpg"
var sNewFileName = selectedSaveDir + sNewDocName;
//alert( "sNewFileName = " + sNewFileName ); // test to verify correct location
var saveFile = new File(sNewFileName);
jpgSaveOptions = new JPEGSaveOptions();
jpgSaveOptions.quality = 12;
docRef.saveAs(saveFile, jpgSaveOptions, true, Extension.LOWERCASE);
In Windows XP, this script works very well in CS2 with no problems.... just in Windows 7 is where this issue occurs using CS2 or CS5.
The problem seems to be similar to : Photoshop Javascript scripting saving and closing document
But I don't know his OS.
I've added the "alert(" and confirmed the save folder & name is correct and can be saved to, but same issue.
Could it be a UAC issue in Windows 7 ? and how do you Fix it ? I've turned off all UAC settings (I think I did it correctly), but it still occurs.
Any Help ?
You missed out " var docRef = app.activeDocument;" (which i've added); but apart from that, in CS2 the script saves out a jpeg to the desktop (wcb-text test.jpg). It's obvious, but have you made sure the image is flattened or doesn't contain any information that cannot be stored in a jpeg - like paths for example.
Try forcing a flatten before saving
//flatten the image
docRef.flatten();
Another thing to try is to save out the file to another directory. I know that long file names (especially with spaces in) can cause problems - I think there's a limit to 300 characters in the file path.
I just found that, in new versions of PS this particular path variable gives the error 8800:
var selectedSaveDir = "~/Desktop/";
Use full path instead and use apostrophes instead of quotes:
var selectedSaveDir = 'C:/Users/yourname/Desktop/';

ExtCreatePen and Windows 7 GDI

I created DIBPATTERN pens with ExtCreatePen API for custom pattern pens.
It sucessfully draws desired lines on Windows XP,
But on Windows 7 (x64 for my case), it does not draw any lines; no changes on screen.
(Other simply created pens, for example CreatePen(PS_DOT,1,0), are working.)
I found that calling SetROP2(hdc, R2_XORPEN) makes the following line-drawing API calls draw something but with XOR operation. I don't want XOR drawing.
Here is my code to create the pen. It has no problem on Windows XP:
LOGBRUSH lb;
lb.lbStyle = BS_DIBPATTERN;
lb.lbColor = DIB_RGB_COLORS;
int cb = sizeof(BITMAPINFOHEADER) + sizeof(RGBQUAD) * 2 + 8*4;
HGLOBAL hg = GlobalAlloc(GMEM_MOVEABLE, cb);
BITMAPINFO* pbmi = (BITMAPINFO*) GlobalLock(hg);
ZeroMemory(pbmi, cb);
pbmi->bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
pbmi->bmiHeader.biWidth = 8;
pbmi->bmiHeader.biHeight = 8;
pbmi->bmiHeader.biPlanes = 1;
pbmi->bmiHeader.biBitCount = 1;
pbmi->bmiHeader.biCompression = BI_RGB;
pbmi->bmiHeader.biSizeImage = 8;
pbmi->bmiHeader.biClrUsed = 2;
pbmi->bmiHeader.biClrImportant = 2;
pbmi->bmiColors[1].rgbBlue =
pbmi->bmiColors[1].rgbGreen =
pbmi->bmiColors[1].rgbRed = 0xFF;
DWORD* p = (DWORD*) &pbmi->bmiColors[2];
for(int k=0; k<8; k++) *p++ = patterns[k];
GlobalUnlock(hg);
lb.lbHatch = (LONG) hg;
s_aSelectionPens[i] = ExtCreatePen(PS_GEOMETRIC, 1, &lb, 0, NULL);
ASSERT(s_aSelectionPens[i]); // success on both XP and Win7
GlobalFree(hg);
Is it bug only on my PC? Please check this problem.
Thank you.
This is a known bug with the Windows 7 GDI, though good luck getting Microsoft to acknowledge it.
http://social.technet.microsoft.com/Forums/en-US/w7itproappcompat/thread/a70ab0d5-e404-4e5e-b510-892b0094caa3
-Noel
I will admit, I was dubious as first, but I compiled and ran your program, and it does indeed fail to draw the second line on Windows 7, buy only in aero mode
By switching to Windows basic or classic mode, all four lines are drawn, as expected.
I can only assume that this is some kind of bad interaction with your custom pen and the new way aero mode implements GDI calls. This seems like it might be a Microsoft bug, perhaps you can post this question on one of their message boards?
So you are creating an 8x8 black/white (monochrome) bitmap as a DIB, and then using that to create a pen. I see nothing wrong with this code. this definitely looks like a windows bug, but there may be a workaround.
Try setting
pbmi->bmiHeader.biClrUsed = 0;
pbmi->bmiHeader.biClrImportant = 0;
In this context, setting the values to 0 should mean the same thing as setting them to 2, but 0 is more standard behavior for situations where you have are using the full palette. You still need two entries in your palette, 0 just means "full size based on biBitCount".
Also, each palette entrie is a RGBQUAD, which means there is room for alpha, and your alpha is set to 0, which should be ignored, but maybe it isn't. so try setting the high byte of your two palette entries to 0xFF or 0x80.
Finally, it's possible that your palette is being ignored entirely, and Windows is using the BkMode, BkColor and TextColor of the destination DC for everything, so you need to make sure that they are set to values that you can see.
My guess is that this has something to do with alpha transparency, since GDI ignores alpha entirely, but Aero doesn't.

Resources