See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.
************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
at ScpServer.ScpForm.ControllerStatusChanged() in c:\Users\Brian\Documents\GitHub\brianfundakowskifeldman-ds4windows\DS4Tool\ScpForm.cs:line 177
at ScpServer.ScpForm.Form_Load(Object sender, EventArgs e) in c:\Users\Brian\Documents\GitHub\brianfundakowskifeldman-ds4windows\DS4Tool\ScpForm.cs:line 104
at System.Windows.Forms.Form.OnLoad(EventArgs e)
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl()
at System.Windows.Forms.Control.WmShowWindow(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at ScpServer.ScpForm.WndProc(Message& m) in c:\Users\Brian\Documents\GitHub\brianfundakowskifeldman-ds4windows\DS4Tool\ScpForm.cs:line 159
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.
When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.
It allows me to continue with the program still though. The version from the other thread doesn't give this message when trying to duplicate it the same way.
Eventviewer doesn't give me anymore detailed info.
I've just wanted to corroborate this error report. In fact, we appear to having the exact same error and it can also be worked around in the same fashion: I've just created a standard, non-admin-privileged account to test this, and it is indeed an error that simply does not occur with a non-admin account, regardless of whether the program itself is given admin privileges or not.
Hopefully, this is of help to you, electrobrains. Otherwise, we can try installing Visual Studio Express and go into deeper debugging.
That is still utterly mysterious; that's the line of code I was suspecting would have to be the problem but I have no idea why that's an issue. Maybe it's validating that ButtonBase.Text should not be set to null? Try this...
Regarding your light bar situation, thanks for explaining exactly what you want to do. I think a user-friendly behavior would be detecting whether the computer is connected to the charger itself, or draining, and giving you the option of shutting off the light bar when the controller is plugged in while the computer itself is charging. For ease of implementation, I wouldn't try to detect whether the controller was plugged into the computer itself to charge, just assume that it is in order to deactivate the light bar.
I'm really trying to rethink light bar and rumble policy for DS4Windows 1.1... using the light bar to supplement rumble effects is I think a really interesting way to add immersion. I want to save it for interesting uses and not worry so much about the mundane ones. I am really liking my earlier idea of only showing the controller identification color animation upon pressing the PS button. In the uncommon case where you need to tell controllers apart, I don't think that is much to ask of the user, and to give them the benefit of better battery life (light bar off) by default.
Edit: added the binary to test, removes the possibility of setting ButtonBase.Text to null (I think.)
(04-03-2014, 04:29 PM)cascardian Wrote: [ -> ]I've just wanted to corroborate this error report. In fact, we appear to having the exact same error and it can also be worked around in the same fashion: I've just created a standard, non-admin-privileged account to test this, and it is indeed an error that simply does not occur with a non-admin account, regardless of whether the program itself is given admin privileges or not.
Hopefully, this is of help to you, electrobrains. Otherwise, we can try installing Visual Studio Express and go into deeper debugging.
Thank you for testing! Please try the attachment I just posted
(04-03-2014, 04:47 PM)electrobrains Wrote: [ -> ]I think a user-friendly behavior would be detecting whether the computer is connected to the charger itself, or draining, and giving you the option of shutting off the light bar when the controller is plugged in while the computer itself is charging.
How come you don't like the user defined idle time light off option (user defines seconds of controller inactivity before light turns off, and on button press, light turns back on)?:
[Charging]
Default Brightness Level = [ ]
Light Idle Off Time = [ ] secs
[Not Charging]
Default Brightness Level = [ ]
Light Idle Off Time = [ ] secs
Yes, the light should turn off when charging is done (if not pressing anything)
Question: If the battery is full and you are using the controller wired, does it stop charging and give the controller direct electrical access or does it keep charging the battery and the controller continuously pulls power from the battery?
Yes, it still gives the error message. I too thank you for continuing.
Is it just me, or have other people noticed that the update to mouse behavior from 1.0 Alpha causes their cursor to once again "snap to grid" sporadically when trying to move it short distances? Before, if the mouse wanted to "snap" the cursor would be dragged smoothly between these points but now it's back to instantaneous leaping. This is particularly irritating in shooters if using the touchpad to aim; the smoothing behavior between leaps helped mitigate how frustrating they were, because your aiming reticle would "drag across" what you were trying to land on, rather than leaping to the other side of it.
(04-03-2014, 08:19 PM)Tox Wrote: [ -> ]Is it just me, or have other people noticed that the update to mouse behavior from 1.0 Alpha causes their cursor to once again "snap to grid" sporadically when trying to move it short distances? Before, if the mouse wanted to "snap" the cursor would be dragged smoothly between these points but now it's back to instantaneous leaping. This is particularly irritating in shooters if using the touchpad to aim; the smoothing behavior between leaps helped mitigate how frustrating they were, because your aiming reticle would "drag across" what you were trying to land on, rather than leaping to the other side of it.
That's exactly the behavior I saw before I made those recent releases with new touchpad jitter compensation algorithms. The touchpad sensitivity also seems to change drastically when it is warm from touch. I should send you a version which logs touchpad activity so we can look at exactly what your controller reports as you use it... I never use anything but Button Mode because it gives me the speed and precision I want. Tapping is not for me.
(04-03-2014, 05:24 PM)shinra358 Wrote: [ -> ]How come you don't like the user defined idle time light off option (user defines seconds of controller inactivity before light turns off, and on button press, light turns back on)?:
[Charging]
Default Brightness Level = [ ]
Light Idle Off Time = [ ] secs
[Not Charging]
Default Brightness Level = [ ]
Light Idle Off Time = [ ] secs
Yes, the light should turn off when charging is done (if not pressing anything)
Question: If the battery is full and you are using the controller wired, does it stop charging and give the controller direct electrical access or does it keep charging the battery and the controller continuously pulls power from the battery?
Yes, it still gives the error message. I too thank you for continuing.
The thing I don't like is that it is a lot of work updating the GUI and adding options right now with the traditional style (not Donbabbeo's) GUI. I don't want to implement something and turn around and replace all the settings; I want us to try and plan out the light bar policy configuration we'd like before I embark down that path at all.
(04-03-2014, 04:29 PM)cascardian Wrote: [ -> ]I've just wanted to corroborate this error report. In fact, we appear to having the exact same error and it can also be worked around in the same fashion: I've just created a standard, non-admin-privileged account to test this, and it is indeed an error that simply does not occur with a non-admin account, regardless of whether the program itself is given admin privileges or not.
Hopefully, this is of help to you, electrobrains. Otherwise, we can try installing Visual Studio Express and go into deeper debugging.
Yeah, I think it's going to be necessary at this point, because I can't reproduce the issue by running as a non-privileged user, either, on Win8.1 amd64. You may also need to download and install the Windows 7 DDK if debugging doesn't work with Visual Studio alone -- or I could probably just send you a copy of the headers. It doesn't need any of the executables, just header and maybe library files.
