Well, all of the Windows-supported libraries present problems, especially if one is building using MinGW rather than Visual C++. Generally, they cannot be built at all without a massive amount of hacking the code bases to make them MinGW-compatible. No DirectShow apps will build, neither will the more-recent MS audio interface (don't recall the name at the moment). However, I found a freeware library called zplay, which is easy to build, open source, and nice, compact code... it also has the ability to play other formats, such as flac... so I'll just go with that... libZPlay multimedia library (Win32)[^]

I am trying to play an mp3 file from a WinAPI/C++ application. I'm using 32-bit MinGW on Windows 10. I found an example program which uses the MCI (winmm) interface to play the file; I found an example command-line program which implements this using mciSendString() calls... I had some problems handling paths to the mp3 file, and *thought* I had fixed it by converting the paths to 8.3 short format... the command-line program plays the files just fine, but when I import exactly the same code into my WinAPI dialog-box application, although the MCI functions all return success, no sound plays... Does anyone have any idea what is missing here?? Or does this library just not work from a Windows dialog app? Here's the code:

  {
  static char short\_str\[MAX\_WAVE\_FILE\_LEN+1\] = "" ;
  CMP3\_MCI MyMP3;
  int result = GetShortPathName (wave\_name, short\_str, MAX\_WAVE\_FILE\_LEN);
  syslog("short: %d: \[%s\]\\n", result, short\_str);
  DWORD lerror = MyMP3.Load(short\_str);
  DWORD serror = MyMP3.Play();
  syslog("MCI: Load: %08X, Play: %08X\\n", lerror, serror);
  }

And here are the load and play functions from his MCI class:

inline MCIERROR Load()
{
std::string szCommand = "open \"" + GetFileName() + "\" type mpegvideo alias " + GetFileName();
return mciSendString(szCommand.c_str(), NULL, 0, 0);
}

inline MCIERROR Load(char *szFileName)
{
m_szFileName = szFileName;
return Load();
}

inline MCIERROR Play()
{
std::string szCommand = "play " + GetFileName() + " from 0";
return mciSendString(szCommand.c_str(), NULL, 0, 0);
}

That's a good point... for most situations that I'm thinking of using this tool, I wouldn't be removing the link once it was installed; it would be for situations such as "open this file in MyEditor", or "run MyUtility on this folder"... but yeah, initially creating the link has to be considered, in either case; My plan was to check for existence of my link when running the program, likely in WM_INITDIALOG.. if it's not there, create it. I mostly write small utilities, so don't always use a dedicated installer...

Okay, I don't have any problem with the Registry API functions, I've used them before. I just expected that ShellAPI would be a more conventional way to do this; something similar to what is done with setting desktop icon colors, where we start with: HWND hwnd = FindWindow("Progman", "Program Manager"); hwnd = FindWindowEx(hwnd, NULL, "SHELLDLL_DefView", ""); hwnd = FindWindowEx(hwnd, NULL, "SysListView32", NULL); [ error handling omitted for clarity ] to gain access to elements under Program Manager... For one thing, the ShellAPI process would eliminate issues with permissions, which I might have with Registry access.. Anyway, I'll look into the links you've mentioned, and try those out.

This seems like a question that should be easy to find an answer to, but I'm not finding anything very convenient... What I will want to do with this, is to be able to right-click on a folder in Explorer, and have an item "run my program on this folder" available... I've found two example programs which do this, but each have drawbacks for my application; 1. one is a C# application (which I'm not familiar with, though it *is* pretty similar). Also, this CodeProject application is using registry modification to do the job; I would prefer to find a link somehow to the Explorer menu, then use InsertMenuItem() from WinAPI to add a link to my application... 2. that brings me to the second example that I found; it's in an older Platform SDK, in a utility called Shell\SampView... that application *does* do what I wish; however, that application is over 8500 lines long!! I am hoping to find a more concise solution to the problem... Can anyone provide any guidance or example code for this?? I use C++, and build with the MinGW (32-bit) toolchain... and yes, I realize that once I get *this* issue resolved, I'll still have a variety of other issues to resolve, such as finding the path to my application, and dealing with selection of wrong items (ideally, perhaps just grey out my menu item if the target is not a folder), and many other things, but for now, I just want to find a concise, clear solution to this one problem.

Actually, that's a good idea... I haven't created an article here in awhile... I did so... here is a link to the article: Determine Time Since Last Logon[^]

Well, since this works so nicely, I thought I would include the complete, working demo function here... however, apparently, I cannot actually attach a file in a message, so I will just link to the file in my Github repository, in the program that it will be used in. derbar/login_lsa.cpp at master · DerellLicht/derbar · GitHub[^] Be sure to enable the STAND_ALONE macro to build stand-alone utility, either in the code, or by putting the macro on the command line, like this:

g++ -Wall -O2 -DSTAND_ALONE=1 login_lsa.cpp -o login_lsa.exe -lsecur32

It works very nicely!!

Ahhh!! So you *are using 64-bit compiler then ?!?! mingw-w64 is the 64-bit compiler... and in my 64-bit compiler, they are also present, but not in the 32-bit compiler... Actually, though, I found a way to make this work with Mingw32... I found the clue in a page for gkrellm application, which has a support file to add support for system functions which are missing in default MinGW-32 package... What he did is use LoadLibrary() to load and obtain a handle for secur32.dll, then used GetProcAddress() to get pointers to the required functions:

hSecur32 = LoadLibraryW(L"secur32.dll");
if (hSecur32 != NULL)
{
pfLELS = (pfLsaEnumerateLogonSessions)GetProcAddress(hSecur32, "LsaEnumerateLogonSessions");
if (pfLELS == NULL)
{
wprintf(L"Could not get address for LsaEnumerateLogonSessions() in secur32.dll\n");
}

That worked beautifully for me!! And yes, your code *does* in fact return the login times that I was looking for; Thank You again!!

Hey, @Randor, that works *great* !!!!!!!!!!! Thank you so much!! I do have *one* minor issue with it, though... Is this intended to be a 64-bit-only operation?? I use MinGW, not Visual C++, for all of my app development, and at this point, I still use a 32-bit compiler... However, I cannot build this with 32-bit MinGW: > g++ -Wall -O2 login_lsa.cpp -o login_lsa.exe -lsecur32 login_lsa.cpp: In function 'INT main()': login_lsa.cpp:14: error: 'LsaEnumerateLogonSessions' was not declared in this scope login_lsa.cpp:17: error: 'PSECURITY_LOGON_SESSION_DATA' was not declared in this scope login_lsa.cpp:17: error: expected ';' before 'pData' login_lsa.cpp:19: error: 'pData' was not declared in this scope login_lsa.cpp:19: error: 'LsaGetLogonSessionData' was not declared in this scope I searched through *all* .h and .hpp files in c:\mingw, and these functions were not declared anywhere... Mind ye, it *does* build and run just fine with 64-bit MinGW. (in case anyone is not familiar with MinGW, it stands for Minimal Gnu for Windows, and is a port of the GNU toolchain to Windows, using Windows libraries for most services.) My MinGW 32-bit toolchain *does* have netsecapi.h and secur32.lib (in its format), but these LSA functions appear to not be included... I also tried current TDM build of MinGW, which is gcc 10.3.0, but it does not contain these functions either...

BTW, I found another site which suggested a console command to display last logon: > net user dan7m | findstr /B /C:"Last logon" Last logon 03/20/21 07:16:26 Interestingly, that is showing exactly the same logon time as NetUserGetInfo(2) is showing... But that is *not* when I last logged on; it's not even when I last rebooted - Uptime is showing 4.5 days, which is correct... I think, maybe, this suggests that the 'logon' time that I'm actually looking for - which is the time since I last logged out of this session and logged in again... is maybe called something else entirely in Windows 10?? I am very confused by all this...

Okay, I changed them to %u, which made no difference. I'm using a 32-bit compiler, so I don't need to specify %lu to get 32-bit values. This is definitely *not* a timezone issue, since the logon time is off by 77 days, not by 8 hours!!

I'm trying to determine this value for a system-status program that I maintain. In the past, I've just shown Uptime, but now that I'm forced to Windows 10, that isn't entirely informative!! If I log out of my machine (shutdown -l) and then log back in, Uptime doesn't get reset. So I want to add an option to show logon time vs reboot time (Uptime)... but I'm not having much success with this... I have found several articles which recommend NetUserGetInfo(), but this is returning invalid data for me... for example, I just logged out, and back in, to my machine... here is the code, followed by the results that I get:

// Call the NetUserGetInfo function.
dwLevel = 2;
wchar_t username[UNLEN+1];
DWORD username_len = UNLEN+1;
GetUserNameW(username, &username_len);
nStatus = NetUserGetInfo(NULL, username, dwLevel, (LPBYTE *) & pBuf);
// skipping result checking
pBuf2 = (LPUSER_INFO_2) pBuf;
wprintf(L"User account name: %s\n", pBuf2->usri2_name);
wprintf(L"Password age (seconds): %d\n", pBuf2->usri2_password_age);
wprintf(L"Last logon (seconds since January 1, 1970 GMT): %d\n", pBuf2->usri2_last_logon);
time_t logon_time = pBuf2->usri2_last_logon ;
char buff[20];
strftime(buff, 20, "%Y-%m-%d %H:%M:%S", localtime(&logon_time));
printf("logon time: %s\n", buff);

The results that I get are:

User account name: dan7m
Password age (seconds): 10221317
Last logon (seconds since January 1, 1970 GMT): 1616249786
logon time: 2021-03-20 07:16:26

Note that the logon time *actually* around 1920 on 06/05/21... So I have two questions, I guess... 1. is there some way to make this function actually work?? 2. if not, how else can I programmatically access the login time on Windows 10 64bit??

First off, let me admit that I'm a newbie at javascript... I spent my career on C and C++, mostly in the embedded realm. So I'm trying to fix some problems with an old html/javascript program called BallDroppings. It was extracting its sound files from a .swf file, using fm.playSound() to play them, and it would hang in most browsers as soon as sound was enabled. So I extracted the sound files into separate .mp3 files, and am using Audio() to play them:

  // fm.playSound(Math.round(vel));//call flash function
  var str = "sounds/sound\_" + ("00" + vel).substr(-2,2) + ".mp3" ;
  // console.log(str)
  // sounds/sound\_07.mp3
  var hdlAudio = new Audio(str);
  hdlAudio.play();      

This is working, initially... however, the nature of the program is that more and more balls (and therefore, sounds) are active as the display becomes more complex. What I'm finding is that, with certain browsers (Firefox and Pale Moon), once a certain number of sounds are active, the system appears to get confused, and the program loses control of the sounds - meaning that, among other things, sound cannot be turned off, and not all sounds that *should* be playing, *are* playing... Interestingly, this issue does not occur with MS Edge; I've had up to 26 balls in flight, and all sounds are working, and can be turned off/on. I haven't tested with Chrome yet. Does anyone have any idea what is wrong here?? Note: the entire project is available for cloning here: GitHub - DerellLicht/BallDroppings: port of ancient BallDroppings app, without dependence upon swf file for sounds[^] If you just want to see it running, use this: BallDroppings[^] draw lines to block the stream and bounce the ball around, click 'Options' and then 'Sounds' to turn sounds on.

I have a console program which I have used for years, for (among other things) displaying info about certain audio-file formats, including mp3. I used data from the mpeghdr site to calculate the frame sizes, in order to further calculate playing time for the tracks. The equation that I got from mpeghdr was:

// Read the BitRate, SampleRate and Padding of the frame header.
// For Layer I files use this formula:
//
// FrameLengthInBytes = (12 * BitRate / SampleRate + Padding) * 4
//
// For Layer II & III files use this formula:
//
// FrameLengthInBytes = 144 * BitRate / SampleRate + Padding

This works well for most mp3 files, but there have always been a small subset for whom this equation failed. Recently, I've been looking at a set of very small mp3 files, and have found that for these files this formula fails *much* more often, so I'm trying to finally nail down what is going on. In all cases, I can successfully find the first frame header, but when I used the above formula to calculate the offset to the *next* frame header, it is sometimes not correct. As an example, I have a file 'wolf howl.mp3'; analytical files such as MPEG Audio Info show frame size as 288 bytes. When I run my program, though, it shows length of first frame as 576 bytes (2 * 288). When I look at the mp3 file in a hex editor, with first frame at 0x154, I can see that the next frame is at 0x154 + 208 bytes, but this calculation *does* in fact result in 576 bytes...

File info:
mpegV2.5, layer III
bitrate=variable

bitrate=32, sample_rate=8000, pad=0, bytes=576
mtemp->frame_length_in_bytes =
(144 * (mtemp->bitrate * 1000) / mtemp->sample_rate) + mtemp->padding_bit;
which equals 576

So what am I missing here?? I've looked at numerous other references, and they all show this equation... At first I thought is was an issue with MPEG 2.5, which is an unofficial standard, but I have also seen this with MPEG2 files as well. Does anyone have any insights on what I am missing here?? //************************************** Later notes: I thought maybe audio format would be relevant to this issue, so I dumped channel_mode and mode_extension for each of my test files (3 calculate properly, 2 don't). Sadly, all of them are cmode=3, mode_ext=0 (i.e., last byte of the header is 0xC4)... so that doesn't help...

Excellent idea!! Thank you, GetCurrentThreadId() will immediately and directly answer this question for me, I'll test it out this morning... Yep, GetCurrentThreadId() confirmed that the callback thread executes in the context of the initiating thread.

I have a technique that I use in WinAPI programs, to avoid stalling the message queue. I start a separate thread in my program, which opens a hidden window with its own message queue. I typically call this thread the CommTask thread, since the first time I did this was to handle slow serial communications. When I want to perform a time-consuming task, I send a message to the CommTask thread using SendMessageCallback(), with a data packet telling it what to do. When the CommTask thread completes handling of my message, my callback function gets executed. What I don't know is, what thread is the callback function executing in?? Is it still in the CommTask thread, or has it somehow returned to my main program thread, or is there some other thread context that it executes in?

How do I call the default handler?? Do I do the same as with a subclassed control: return CallWindowProc (lpfnEditWndProc, hWndEdit, msg, wParam, lParam); At this point, this is not a subclassed function.

I have a dialog-based application, and I use a portion of the dialog for drawing some graphics. I have a problem when I minimize and then restore the dialog... I handle WM_SIZE (wParam == SIZE_RESTORED) to redraw my graphics, but this doesn't work because WM_PAINT occurs afterwards and redraws the entire dialog, leaving my graphics area blank. I tried moving my update function to WM_PAINT, but even that doesn't work, because the system redraws the dialog after my handler returns!! How is this problem typically solved?? For now, I'm going to start a 50msec timer in WM_SIZE, and redraw my graphics in that, then stop the timer. I've used this trick before, and it works well enough, but I know that's not how this is supposed to be done!!

Please clarify... when you say "I just tried the above code and it works fine.", do you mean you put the code fragment that I printed, in another program and ran it? I was hoping you downloaded and built my sample code... I guess that would be a problem if you don't use MinGW. I agree that it is something in my code, but I'm damned if I can figure out what !! I'm comparing the stripped-down failing code against another working Win32 utility that I have (where the button code works fine), and for the life of me I cannot figure out what the difference is!! What I'm doing now, is I made a copy of the working project, and am pasting pieces of my target project into it, one piece at a time, until I hopefully find what breaks the color dialog. My great fear is that I'll never find it, and the copied project will work fine - and I'll NEVER figure out why this one is broken... :wtf: //************************ Later note: yeah, I got the application completely ported over from the original project to the new project based on a dialog where the ChooseColor() worked properly, and the entire project works fine. Of course, I can't find any difference between the two, that could explain the original problem. I guess I'll never know...

Huh?!?!? You can select cells in the color dialog, and the cancel/okay buttons work?? That's bizarre... Did you build with MinGW ? If so, what version? (though I don't think that matters)... I also went back to another small dialog-based application that I wrote some time ago, and pasted the select_color() function into it and called it from a button, and that worked fine as well. This is really twisting my brain in a knot !!!!!