ZFX + Developia

Debug console hat geschrieben:First-chance exception at 0x000007fefd6dcacd (KernelBase.dll) in .exe: Microsoft C++ exception: _com_error at memory location 0x0025e800..
First-chance exception at 0x000007fefd6dcacd (KernelBase.dll) in .exe: Microsoft C++ exception: _com_error at memory location 0x0025e760..
First-chance exception at 0x000007fefd6dcacd (KernelBase.dll) in .exe: Microsoft C++ exception: _com_error at memory location 0x0025eaa0..
First-chance exception at 0x000007fefd6dcacd (KernelBase.dll) in .exe: Microsoft C++ exception: _com_error at memory location 0x0025e800..
First-chance exception at 0x000007fefd6dcacd (KernelBase.dll) in .exe: Microsoft C++ exception: _com_error at memory location 0x0025e760..

• Die Größe der Reports eines HIDs ist konstant. Beim Start der Anwendung (oder, sobald ein neues Gerät angeschlossen wird) enumeriert man alle angeschlossenen Geräte.
• Mit den Preparsed Data (also der Protokolldefinition) ruft man HidP_GetCaps() auf. Damit bekommt man die Eigenschaften des HIDs angezeit, wozu auch die Größe eines Reports gehört.
• Von allen Reportgrößen bestimmt man das Maximum. Dazu berechnet man die Unkosten durch RawInput-Header, die vor dem Report platziert werden.
• Einen Speicherbereich dieser Größe allokiert man einmal und nutzt ihn, um die Daten jeder WM_INPUT zu empfangen.

Krishty hat geschrieben: Warum ist beim Erstellen einer Antwort hier auf ZFX der Eingabefokus nicht im Antwortfeld? Ich habe hier bloß ein Touchpad, das außerdem fast einen Meter von mir wegsteht. Ich will ALLES via Tastatur bedienen können. Was wollt ihr denn machen wenn ein körperlich schwer Behinderter auf ZFX Rants über falsch implementiertes Clipping in den Jammer-Thread klatschen will? "Dummes ZFX. Lässt mich nicht meine Antwort eingeben."

eXile hat geschrieben:Für extended-length-Pfade gilt: Stellt man das \\?\ einem Pfad voran, welcher / als Separator enthält, so schlägt CreateFile fehlt. Dahingegen klappt es bei Pfaden mit \ als Separator problemlos.

MSDN hat geschrieben:Note File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\\?\" prefix as detailed in the following sections.

...

For file I/O, the "\\?\" prefix to a path string tells the Windows APIs to disable all string parsing and to send the string that follows it straight to the file system.

kaiserludi hat geschrieben:Die Fehlermeldung ist also einfach nur sehr ungünstig, da sie als Folgefehler eines Errors "could not deduce template argument" verhindert, dass der "could not deduce template argument" Fehler überhaupt angezeigt wird.

kaiserludi hat geschrieben:Bei template<typename FType> void doSomething(int param); ist natürlich klar, dass der Compiler keine Möglichkeit hat an Hand des Aufrufs herauszufinden, für was für einen Typ für FType er die Funktion nun instanziieren soll.
Bei template<typename FType> void doSomething(typename ConfirmAllowedType<FType>::type param); hingegen verfügt er doch über FType in der Signatur, ist aber anscheinend überfordert, den Typ für FType zu ermitteln, wenn er als Parameter statt einem FType ein komplexeres Konstrukt bekommt.

template<typename CType> struct ConfirmAllowedType { static const bool value = false; };
template<> struct ConfirmAllowedType<short> { static const bool value = true; };

// enable_if ist Teil von C++11!
template <bool B, class T = void> struct enable_if;
template <class T> struct enable_if<true, T> { typedef T type; };

class Foo
{
public:
        void doSomething(void);
        template<typename FType> typename enable_if<ConfirmAllowedType<FType>::value>::type doSomething(FType param);
};

template<typename CType> struct ConfirmAllowedType;
template<> struct ConfirmAllowedType<short> { typedef short type; };

template <class B, class T = void> struct enable_on { typedef T type; };

class Foo
{
public:
        void doSomething(void);
        template<typename FType> typename enable_on<ConfirmAllowedType<FType>::type>::type doSomething(FType param);
};

template<typename CType> struct ConfirmAllowedType;
template<> struct ConfirmAllowedType<short> { typedef short type; };

class Foo
{
public:
        void doSomething(void);
        template<typename FType> void doSomething(FType param, typename ConfirmAllowedType<FType>::type* = nullptr);
};

kaiserludi hat geschrieben:Meine Lösung vorhin war, statt typename ConfirmAllowedType<FType>::type weiterhin einfach nur FType zu übergeben und dann in der ersten Zeile im Body der Funktion, in der ich eh für einen statischen Assert auf ein static Member von FType zugegriffen habe, statt FType nun ConfirmAllowedType<FType>::type zu verwenden, da ie Deduktion an der Stelle ja schon erfolgt ist und der ganze Zweck hinter ConfirmAllowedType eh nur ist, die Verwendung nicht unterstützter Typen bereits zur Compilierzeit und nicht erst zur Laufzeit abzufangen.

kaiserludi hat geschrieben:Deine Varianten sehen allerdings auch interessant aus.

kaiserludi hat geschrieben:Nur: In den ersten beiden Fällen habe ich dann ja einen Rückgabewert, den auch irgendwer auslesen könnte, im letzten Fall einen zusätzlichen Parameter, bei dem auch jemand versuchen könnte, was anderes als den Default zu übergeben, sprich ich verkompliziere quasi in allen 3 Fällen das Interface mit Dummies, bei denen ein Aufrufer sich erst wieder im Klaren sein muss, daass es sich um Dummies handelt.

kaiserludi hat geschrieben:PS: Müsste typename ConfirmAllowedType<FType>::type* = nullptr nicht typename ConfirmAllowedType<FType>::type* someExtremelyCoolParameterName = nullptr heißen?