Dooo :
You are right. Instead of using the attach and detach processes, I could probably use the load and unload functions to initialize it. Thanks for the tip. If it still not works, then I bite into the table
Hi Mike,
I don't understand if TBDI_Close is your internal function or thinBASIC keyword.
I think for de-initialization part of thinBASIC module is dedicated function called UnLoadLocalSymbols.
It looks something like this in SDK template:
[code=thinbasic]
'----------------------------------------------------------------------------
FUNCTION UnLoadLocalSymbols ALIAS "UnLoadLocalSymbols" () EXPORT AS LONG
' This function is automatically called by thinCore whenever this DLL is unloaded.
' This function CAN be present but it is not necessary. If present, this function
' will be executed by thinBasic core when module will be released.
' Use this function to perform uninitialize process, if needed.
'----------------------------------------------------------------------------
'---
'Add here DeInitialization code if needed
'---
FUNCTION = 0&
END FUNCTION
[/code]
I don't use LibMain at all. But maybe I get your problem wrong.
Anyway, have a nice day ( and dinner ),
Petr
Learn 3D graphics with ThinBASIC, learn TBGL!
Windows 10 64bit - Intel Core i5-3350P @ 3.1GHz - 16 GB RAM - NVIDIA GeForce GTX 1050 Ti 4GB
Dooo :
You are right. Instead of using the attach and detach processes, I could probably use the load and unload functions to initialize it. Thanks for the tip. If it still not works, then I bite into the table
Double dooooo : Eros allready mentioned Petr's tip. Man, I am sooooo blind. It is a wonder that I ever get things done. :-[
Hi Mike,
thanks a lot. Feel free to send me whatever you want me to check.
As Petr suggested, thinBasic do not handle LIBMAIN function. That function is handled automatically by the operating system.
thinBasic execute LoadLocalSymbols function at module calling and UnLoadLocalSymbols function when script stop execution.
Ciao
Eros
PS: you are too fast to post !!!
www.thinbasic.com | www.thinbasic.com/community/ | help.thinbasic.com
Windows 10 Pro for Workstations 64bit - 32 GB - Intel(R) Xeon(R) W-10855M CPU @ 2.80GHz - NVIDIA Quadro RTX 3000
Using LIBMAIN can be too late or too early because thinCore is not aware of what is going on at that precise time.
That's why we introduced LoadLocalSymbols and UnLoadLocalSymbols. thinCore is responsible to call them exactly when needed. And at that time all global variables inside the script are already there.
Another reason is to hide internal module development to users trying to check internal functions. Only LoadLocalSymbols and UnLoadLocalSymbols are exported. This will keep thinBasic modules usable only by thinBasic interface because all is internal executed by code pointers to functions.
Ciao
Eros
www.thinbasic.com | www.thinbasic.com/community/ | help.thinbasic.com
Windows 10 Pro for Workstations 64bit - 32 GB - Intel(R) Xeon(R) W-10855M CPU @ 2.80GHz - NVIDIA Quadro RTX 3000
Forgive the thread necromancy, but since this was never properly answered, I am answering it for any newcomers who may stumble on this issue.
Although I have not played with the DI commands, Mike's coding is always very solid and reliable.
The problem is DirectInput was not designed for the controller you are trying to use. NexGen (X360) controllers do not work properly under DirectInput. One example (from memory), is left and right buttons are handled as a single axis. Vibration usually does not work properly and there are many other issues which I can't remember.
As of 2005, you should be using XInput for all X360 controllers. XInput is compatible with XP SP1/DirectX 9 and above, so it should work with pretty much any system out there.
DirectInput can still be used for non-X360 controllers, but DirectInput was officially deprecated in 2011, and WM_INPUT should be able to handle most non-X360 controllers just fine.
Since 2011, Microsoft has strongly recommended that you do not use DirectInput for mouse or keyboard control. Microsoft now requires you to solely use WM_INPUT for keyboard and mouse. DirectInput never properly handled mouse and keyboard in all instances anyway, which is why Mark Sibly had to drop DirectInput in early versions of Blitz Plus and used WM_INPUT instead for keyboard/mouse input. DirectInput does not queue actions and was very problematic when using multiple windows.
Hopefully, this helps any newcomers who may encounter a problem and stumble on this thread when searching for a solution.
Digged up from the grave
Guess if there is any need, I could look into integrating XInput.
Bookmarks