I finally discovered (by experiment) that "Lock Juke" actually will put the
jukebox to sleep, vs. shutting the program down completely. Problem is,
there is a black screen (good...) but with a banner that says "Event In
Progress". I can't seem to find any .ini, registry setting, etc. where
you can change it - either remove the banner or change the label. I assume
then the label must be baked in (i.e. hard-coded). Is this a good
assumption, or am I missing something? Also, if you touch the banner,
it will bring up the "now playing" screen - so the jukebox isn't
really asleep if someone can just touch the screen and get a response.
Is there a setting somewhere to disable that? Also... If you wait until
a song finishes playing, when the "No Song Playing" appears, then do
the "Lock Juke", then again to "unlock the juke", the last song that
played (remember, it said "No Song Playing") starts playing again from
the beginning. Any reason for this?
Both of these sound like bugs, I have noted them down and will take a look later today.
Thanks... I had posted another question about the
jukebox providing a status output for different
operating modes/conditions. The most important
would be the sleep/hibernate (what I guess you
call "lock" mode). If the box is asleep, besides
a black screen (optional - if you had at least
a registry entry for a label/banner on the
sleep/"lock" screen), a commercial operator would
want to disable any coin or currency acceptor.
Same goes for marque lighting. Those would go dark
when the box is asleep. Obviously some custom
external circuitry would be required, but any
method needs a status input from the box as
to what state it's in. It looks like some, if
not all iPAC modules have a way of outputting
the status of the keyboard LED's - i.e. Caps
Lock, Num Lock, Scroll Lock. I assume whatever
keyboard driver you are using would have some
API method to set these on/off. Cheap and
dirty...
Maybe while fixing the lock juke issue you
can implement the status idea?
You mentioned we should always be using the
latest Beta. I suppose that's where the bug
"hot fixes" go... Problem is, sometimes we
might have some regressive issue (where
something that worked before, became,
how should I say... affected by a seemingly
unrelated change. So, a Beta is sent out
to the testers for acceptance. IOW using
a Beta always poses some additional risk.
Something a commercial operator wants/needs
to avoid.
Thanks so much for the reply. I'm continually
impressed by the program and realize that
a "metric" :) ton of work must have gone
into it. I sure wish there were more written
documentation...
BTW, below I've attached a question I sent
out Aug 24, regarding sliders. Any help on
that would be appreciated.
-----------------------------------------
RE Nav Slider:
Is there a way to find out, or set, the spacing of the letters
when you click on page-up/page-down, etc.? For example, if
you wanted a larger nav slider gadget, with larger letters,
and obviously a larger "bubble" or square box, etc. as a
"pointer", how or where would you find the values that
define these? The background for the slider is "etched"
on the page screen, so out comes Photoshop... But what
about the graduations of the letters and their spacing?
If you change the length of the slider gadget in skintool,
will that change the spacing between the letters (and how
can we then find out what it is or measure it) - or is
there some numeric definition in one of the ini files? Or
is that baked-in (hard-coded) and you need to keep the
existing slider dimensions?
Question 2... Is there a way to put a slider control option
on the skintool dropdown for the Genre screen, in addition
to jump-to-letter? Is there an ini somewhere that can
enable/disable that feature, or is it "baked-in"?
Question 3... I have seen some skins that have two nav
arrow buttons: one seems to scroll one-by-one, the other
advances full pages. Is this feature only available on
some pages/screens? What or where or how would it be
enabled?
Question 4... Does the ini file structure have a "reserved"
character (like ';' in C) to indicate the start of a
comment? It would be helpful to know which ini entries
do what, etc. By some experimentation, I have found
things like theme, font size/color (on some), x/y
position etc. If there only was a line-by-line list
at least so we could amend the existing ini's with
comments that define what that particular entry/value
does. Would go a long way to fully utilize the
incredible flexibility built in the program.
Thanks again...
Ok, I have been working on it and have hit a stumbling block. I am hopeful to get something out tomorrow. I am having an issue with the CAPS LOCK light and getting it to toggle correctly, this has introduced some other issue with the random play and I have messed up some things. Spent a good few hours on it and think I am close to having it all up and running.
Thanks for the update... So I guess the Lock Screen banner (Event in Progress)
no longer reacts to a click/touch and brings up the Now Playing screen? And maybe
you have a registry (the cheap and dirty way) entry where you can change the
"Event in Progress" to blank ("") or whatever label the operator wants? And
the last song played doesn't play again?
I'm happy you will implement the status output idea... Not sure how you
interface with the keyboard. Waaaaaay back when, I did a project where
the front panel of a device emulated a keyboard. Put a PIC uController
on it so a push of a button would generate a "keypress". Detected the
LED status from the PC (actually used a single-board-PC running embedded
DOS). Worked great, except DOS let me access the keyboard controller
hardware - I don't think it's the easiest thing in the Windows world.
I did however, find a Windows API out there in the ozone (might be
what you are already using). I tried to attach it (BYW, it's in C++),
but got a message the upload directory is full. So, see below...
Thanks again. I wonder up to now how the commercial operators handled
the pause/sleep mode and coin/bill acceptors? Unless they just power
off the machine.
---------------------------------------------------------------------------
On Windows, the HidD_SetOutputReport function is used to control keyboard LEDs by sending a Human Interface Device (HID) output report to the top-level keyboard collection. For standard keyboards, this involves setting a single byte in the output report to specify the state of the Num Lock, Caps Lock, and Scroll Lock LEDs.
The process for controlling standard keyboard LEDs
Obtain a device handle. You must first get a handle to the keyboard's top-level HID collection. You can do this by using the SetupDi... functions and then CreateFile with dwDesiredAccess=0 and dwShareMode=(FILE_SHARE_READ | FILE_SHARE_WRITE).
Determine the report format. To know the correct size and structure of the output report, you can use HidP_GetCaps. This function provides a HIDP_CAPS structure, and the OutputReportByteLength member tells you the required buffer size. For a standard keyboard, the report is typically 1 byte long (plus a leading Report ID if used).
Construct the output report. You will need to create a buffer that represents the output report.
If the report descriptor does not use report IDs, the first byte of the buffer must be 0.
If report IDs are used, the first byte must be a non-zero report ID that corresponds to the LED report.
The second byte (or the first, if no report ID is used) contains a bitmask for the LEDs.
Bit 0: Num Lock
Bit 1: Caps Lock
Bit 2: Scroll Lock
Example: A value of 0x03 (00000011 in binary) would turn on both Num Lock and Caps Lock.
Call HidD_SetOutputReport. Once the report buffer is prepared, you call the function with the device handle, the buffer, and its length.
Example C++ code using the HID API
cpp
#include <iostream>
#include <windows.h>
#include <setupapi.h>
#include <hidsdi.h>
#include <hidpi.h>
#include <vector>
// Link with hid.lib and setupapi.lib
#pragma comment(lib, "hid.lib")
#pragma comment(lib, "setupapi.lib")
void SetKeyboardLEDs(HANDLE hDevice, BYTE ledState) {
PHIDP_PREPARSED_DATA ppd;
if (HidD_GetPreparsedData(hDevice, &ppd)) {
HIDP_CAPS caps;
if (HidP_GetCaps(ppd, &caps) == HIDP_STATUS_SUCCESS) {
std::vector<BYTE> reportBuffer(caps.OutputReportByteLength);
// Set the report ID if the descriptor includes them, otherwise it's byte 0
if (caps.NumberOutputButtonCaps > 0 && caps.ReportID) {
reportBuffer[0] = caps.ReportID; // or the correct report ID
reportBuffer[1] = ledState;
} else {
reportBuffer[0] = ledState;
}
if (HidD_SetOutputReport(hDevice, reportBuffer.data(), reportBuffer.size())) {
std::cout << "Successfully set LED state: " << (int)ledState << std::endl;
} else {
std::cerr << "HidD_SetOutputReport failed: " << GetLastError() << std::endl;
}
}
HidD_FreePreparsedData(ppd);
}
}
int main() {
GUID hidGuid;
HidD_GetHidGuid(&hidGuid);
HDEVINFO hDevInfo = SetupDiGetClassDevs(&hidGuid, NULL, NULL, DIGCF_PRESENT | DIGCF_INTERFACEDEVICE);
if (hDevInfo == INVALID_HANDLE_VALUE) {
std::cerr << "SetupDiGetClassDevs failed: " << GetLastError() << std::endl;
return 1;
}
SP_DEVICE_INTERFACE_DATA deviceInterfaceData;
deviceInterfaceData.cbSize = sizeof(SP_DEVICE_INTERFACE_DATA);
// Iterate through all HID devices
for (DWORD i = 0; SetupDiEnumDeviceInterfaces(hDevInfo, NULL, &hidGuid, i, &deviceInterfaceData); ++i) {
DWORD requiredSize = 0;
SetupDiGetDeviceInterfaceDetail(hDevInfo, &deviceInterfaceData, NULL, 0, &requiredSize, NULL);
std::vector<BYTE> detailBuffer(requiredSize);
PSP_DEVICE_INTERFACE_DETAIL_DATA_A deviceInterfaceDetailData = (PSP_DEVICE_INTERFACE_DETAIL_DATA_A) detailBuffer.data();
deviceInterfaceDetailData->cbSize = sizeof(SP_DEVICE_INTERFACE_DETAIL_DATA_A);
if (SetupDiGetDeviceInterfaceDetail(hDevInfo, &deviceInterfaceData, deviceInterfaceDetailData, requiredSize, NULL, NULL)) {
HANDLE hDevice = CreateFileA(deviceInterfaceDetailData->DevicePath, 0, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL);
if (hDevice != INVALID_HANDLE_VALUE) {
HIDD_ATTRIBUTES attrib;
attrib.Size = sizeof(HIDD_ATTRIBUTES);
if (HidD_GetAttributes(hDevice, &attrib) && attrib.UsagePage == 0x01 && attrib.Usage == 0x06) {
// Check for Keyboard usage
std::cout << "Found keyboard: " << deviceInterfaceDetailData->DevicePath << std::endl;
SetKeyboardLEDs(hDevice, 0x01); // Set Num Lock ON (0x01)
Sleep(2000);
SetKeyboardLEDs(hDevice, 0x02); // Set Caps Lock ON (0x02)
Sleep(2000);
SetKeyboardLEDs(hDevice, 0x00); // Turn all LEDs OFF
CloseHandle(hDevice);
break; // Stop after finding the first keyboard
}
CloseHandle(hDevice);
}
}
}
SetupDiDestroyDeviceInfoList(hDevInfo);
return 0;
}
Forgot to mention...
If you are using the simulated Caps Lock keypress to control the LED,
Remember it's toggle (i.e. alternate-action). But so is the Lock-Juke
button (whatever key it gets assigned to). Both being toggle, there
might be a possibility that they could get out-of-sync. I suppose an
error check would be to test the Caps Lock function after the Lock Juke
was keyed in to make sure the LED followed the correct toggle state.
BTW, if you get time... The questions about the slider controls:
Is there a way to find out, or set, the spacing of the letters
when you click on page-up/page-down, etc.? For example, if
you wanted a larger nav slider gadget, with larger letters,
and obviously a larger "bubble" or square box, etc. as a
"pointer", how or where would you find the values that
define these?
Is there a way to put a slider control option
on the skintool dropdown for the Genre screen, in addition
to jump-to-letter?
I have seen some skins that have two nav
arrow buttons: one seems to scroll one-by-one, the other
advances full pages. Is this feature only available on
some pages/screens? What or where or how would it be
enabled?
So glad you're here to help...
Gee, I hate to bug you, but another idea that may be easier
to implement:
To generate a status output (lock juke or anything else), you
can have the user get a USB serial port emulator device. Most,
if not all implement the typical RS-232 control lines. In our
case (output) you can use the RTS (request-to-send) or DTR
(data terminal ready) or both if there is a requirement for
an additional status output. Very easy to set up with WIN32
API...
As far as setup goes, back to the trusty registry. Add another
key to E-Touch 8 that you would put in the virtual com port,
default baud rate, etc., and what status signal (lock juke
for now) you want to associate with RTS, DTR, etc. Future
use could use the control line inputs as well. Save that
for another day. Since this feature would only be applicable
to the commercial operator, there's no reason to clutter up
the configuration screens/tabs with something rarely used.
The main benefit is that you won't have any potential sync
issue with toggling the Caps Lock key on the keyboard.
I realize this would not be for the "casual" user (who
shouldn't even know what a registry is, let alone dabble
in it..., and they would need some RS-232 to TTL (or
whatever) device to translate the USB com port signal outputs -
those are all over Amazon for next to nothing. Obviously,
they would need some electronic background to properly
interface any status signal with the coin/bill acceptor
enable lines anyway.
Hope this helps, and maybe saves you some work...
Thanks...
Check out the new beta. I went for the CAPS Lock option as i had already done some work on it. It was also much easier that adding some RS232 stuff. I could possibly implement the RS232 stuff but it is a lot of work and I am really only maintaining it and bug fixing right now. I can add things if they are easy enough to do but more complicated additions I am not sure. Hopefully this resolves some of the issues for you.