|
aeskan wrote: Briefly, could we connect an electrical switch without any circuit or board to USB port to do something simple in our application?
No, as a USB port doesn't know how to interpret a "row" of switches. There's various projects, with prebuild general-purpose controllers and open source to control the hardware, like this one[^]. Alternatively, find a cheap USB-joystick and a large hammer 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Thank you Eddy for reply.
|
|
|
|
|
Connect a switch to a USB "port", hit the switch just once and you'll short the USB out and possibly kill the USB controller on your motherboard.
USB ports are not "ports". USB is a BUS, not unlike the expansion slots (bus) inside your PC. Without an interface chip on the switch to tell USB that a device is there, you cannot listen for the changes in the switch.
|
|
|
|
|
|
As other have already pointed out. Direct connection to USB is hazardous to the health of the USB ports.
However, perhaps if you got hold of a USB-Serial adapter it should be possible to use it on the Carrier Detect/CTS/RTS/DTR/DTS. whichever is available at the serial port.
an additional smoothing capacitor & resistor above 1K-ohms in series should help filter out the switching noise/limit current demand.
|
|
|
|
|
Thank you dusty_dex, that's what I was searching for. 
|
|
|
|
|
Hi again.
I am a little confused about setting up delegates. I believe this is correct:
If I have a number of individual statements such as:
MyLocalTreeView.TreeView1.SelectedNode.Parent.FullPath
MyLocalTreeView.TreeView1.SelectedNode.FullPath
MyLocalTreeView.TreeView1.SelectedNode.Expand()
Me.MyLocalTreeView.TreeView1.Focus()
am I correct in assuming that separate delegates for each must be built, if they do not all happen together in some recurring usage where they would all be lumped together in one sub?
Thanks for your help!
|
|
|
|
|
Are you using the term "delegate" correctly? Delegates are basically function pointers that can be passed around like variables. In VB.NET delegates are created using the AddressOf operator. See this: Delegates in VB.NET[^]
Maybe I'm not getting what you are trying to do? Are you talking about a subroutine to do all the above operations in one call?
|
|
|
|
|
Hi, Ron. Thanks for your response.
I am referring to the fact that a form's controls cannot be directly accessed via a thread other than the main thread that runs the form itself. Delegates are required. That being the case, if I have a TreeView that must be updated from a second thread, do I need to create separate delegates for each and every method I will use for the TreeView? It seems that unless I always use multiple TreeView methods in a set order, and put all of that into a sub that will have a delegate assigned to it, then I will need to do them all separately.
Hm...just thought of this...Unless it is possible to create a delegate for the entire TreeView class.
|
|
|
|
|
Yeah, "delegate" is not the right term.
Operations on UI items can only be performed on the thread that created them, typically (almost always) the UI thread. When you want to do something, you have to Invoke on the UI thread. Don't confuse the word invoke with delegates, a delegate can be invoked, but its really not the same concept. You can create a delegate to invoke on the UI, but there are other options.
The Control.Invoke method invokes on the UI thread, you don't have to use the TreeView.Invoke for just treeview items, you can update any UI item in that invoke call since its running in the UI thread. You can even run complicated sets of code in there if you want that have nothing to do with the UI.
|
|
|
|
|
Ah, cool. Thanks for the clarification. I think you just made my day in getting my mind around delegates and Invoke, and how they relate.
|
|
|
|
|
This may be of help for referencing items on a separate thread:
Create an extension method to invoke items:
Module Extensions
<Runtime.CompilerServices.Extension()> _
Sub SynchronisedInvoke(synchMe As ISynchronizeInvoke, action As Action)
If Not synchMe.InvokeRequired Then
action()
Else
synchMe.Invoke(action, New Object() {})
End If
End Sub
End Module
Then you can reference the item on the other thread with the use of a lambda:
lblMessage.SynchronisedInvoke(Sub() lblMessage.Text = "Hello World")
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Sorry for responding late. My A/C went out last night, and I need to get a window unit in for temporary use. In the meantime, it is 91degF inside my home and I can only use my laptop for brief stints, that with a cooler pad underneath. My desktop computer needs to stay shut down.
|
|
|
|
|
Hi
Can some one help. I'm trying to run the following script but nothing happens
Option Explicit
Public objShell
dim in = "C:\test3.pdf"
dim out = "C:\test4.ps"
set input = in
set output = out
Set objShell = WScript.CreateObject ("WScript.shell")
objShell.run "c:\pdftops.exe -nocrop -noshrink -level3 %input% %output% "
|
|
|
|
|
First, I assume you have run the pdftops.exe file with the defined inputs from a command prompt and it worked correctly.
Having said that, are you sure the input and output parameters are even being passed to the command line?
My suggestion, build the command line and replace the input/output parameters with the actual equivalents.
sCommand = "c:\pdftops.exe -nocrop -noshrink -level3 " & in & " " & out
objShell.run sCommand
|
|
|
|
|
Of course it doesn't work. The command line you ran was exactly:
c:\pdftops.exe -nocrap -noshrink -leve3 %input% %output%
VBScript does NOT do "automatic" variable replacement in strings. A string it treated as literal. The contents are not modified by what is in the string.
|
|
|
|
|
Further to the other comments, SET in vbscript doesn't set an environment variable; it assigns the reference-type value on the right-hand side to the variable on the left-hand side. Since you've specified Option Explicit and you haven't declared the input or output variables, this should fail.
http://msdn.microsoft.com/en-us/library/4afksd44%28v=vs.84%29.aspx[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
1. in is a keyword. Do not use it.
2. Write the strings something like this...
objShell.run "c:\pdftops.exe -nocrop -noshrink -level3" & input & " " & output
Beauty cannot be defined by abscissas and ordinates; neither are circles and ellipses created by their geometrical formulas.
Source
|
|
|
|
|
Hi, all.
Once again, vb.Net shows how convoluted it can be. Or I'm just stupid.
Assume I have a background thread running. Then, if in the Immediate window, I type in
?m_Thread.ThreadState.ToString
I get back, "Background".
But if I first assign ThreadState to a string variable:
Dim ThreadState_str As String
ThreadState_str = m_Thread.ThreadState.ToString
and type in
?ThreadState_str
I get back:
"Background, WaitSleepJoin"
What is going on here?!
|
|
|
|
|
ThreadState is an enumeration. In the first case, the thread has the IsBackground set, which shows up at Background at the Thread.ThreadState property.
In the second state, the thread is blocked by a wait or join.
Such behavior of the ToString method is due to the FlagsAttribute[^] and the Enum.ToString method[^].
See
ThreadState@MSDN[^] for more details.
Beauty cannot be defined by abscissas and ordinates; neither are circles and ellipses created by their geometrical formulas.
Source
|
|
|
|
|
Thanks, Amitosh.
Seems awfully convoluted. But that's Microsoft, I guess.
|
|
|
|
|
You should not rely on the string representation of an object they are likely to change. You should evaluate the values.
Beauty cannot be defined by abscissas and ordinates; neither are circles and ellipses created by their geometrical formulas.
Source
|
|
|
|
|
That's what is annoying about it. When you take the string representation of an object at any given moment via the ToString method, nothing should change in that moment, and it should be valid as a value. For in that moment, you pulled out a piece of information that in many cases will be used immediately. If vb allows the printing of a value from ThreadState, then that should be the same thing as "printing" it to a string which is nothing more than a storage spot for the same thing. It should be, anyway.
|
|
|
|
|
Schrodinger's cat... the very act of observing the sate can chance the state.
|
|
|
|
|
It makes complete sense and is not convoluted at all. By the way, it's not VB doing it, it's Visual Studios debugger and YOU!
When you stop the app, the debugger stops all the threads in it, therefor modifying their state. But, it's not entirely stopped. When you get the value of a property, the debugger executes the property Get code, so the thread isn't entirely stopped.
As was already mentioned, the act of viewing an object changes it's state!
You're still doing a fair bit of bashing of VB.NET/.NET without trying to understand what's going on under the covers and why.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
