Prev: Thanks to all contributors & results
Next: How can I implement jagged arrays in VB6? UDT?
From: Tom Shelton on 1 Jun 2010 11:11
Schmidt presented the following explanation :
> "Tom Shelton" <tom_shelton(a)comcast.invalid> schrieb im Newsbeitrag
> news:hu1nr0$csv$1(a)news.eternal-september.org...
>
>> That said, since there is almost a mandatory requirement
>> to create at least one thread in a service app,
> That's what e.g. NTSvc.ocx does under the hood - the
> communication-thread for the Service-Manager runs
> "within" that OCX, visible in the MainThread of the
> normal VB-App are only the thrown Events of this OCX.
>
>> It's been a while, but isn't that option only available to
>> ActiveX exe's?
> No - you can deal with such threads (as the one
> required for ServiceManager-interaction) also
> per Typelib-approach directly in VB5/6 - and
> that's what Sergeys example does for the few
> required Messages, which come in from that
> "communication-thread".
>

I know that. That's not the question. I was talking about the
Unattended execution project option...

I realize you can create threads in a standard exe. But since we were
not even talking about the example you posted further down the thread,
I'm not sure why you bring this up here.

> Somewhat sad BTW, that you don't even try -
> to stay true to your own words (posted only a
> few days ago) - to not pester the group with
> ".NET-suggestions" anymore.
>
I have not suggested .NET at all. I'm not sure where you got that
impression - but I suggest you go back and re-read what I said. Yes, I
mentioned .NET - but, not in the context of suggesting the OP switch or
use it... Just to implement something similar.

--
Tom Shelton


From: Schmidt on 1 Jun 2010 14:43

"Tom Shelton" <tom_shelton(a)comcast.invalid> schrieb im Newsbeitrag
news:hu380f$5kf$1(a)news.eternal-september.org...
> Schmidt presented the following explanation :

> I know that. That's not the question. I was talking about
> the Unattended execution project option...
This option is more a "compile-time"-option -
which supresses e.g. MsgBoxes (even if those are
coded and called in such a Project) from popping-up.
Standard-VB-Forms are not allowed to define there.

Timer-Controls (which need a VB-Form or Usercontrol
as a Container) can be replaced with one of the
class-based Timers which are available "all over the Web".
For example this one here works pretty well:
http://www.vbforums.com/showthread.php?p=3790920

Also the CreateWindowEx-APIs (to create your
own windows, if you need them for example for
your own class-implementation of the Winsock-API)
do work without problems, even when Unattended
Execution was switched on (even when running under
the system-account as a service later on).

> I realize you can create threads in a standard exe.
> But since we were not even talking about the example
> you posted further down the thread,
> I'm not sure why you bring this up here.
Because you said:
"You can use SetTimer/KillTimer has has already
been suggested - but you still need a message loop.
Because of that you will probably want to wrap
it in an object that is on a background thread"...
....
Followed by your usual "suggestions" - how easy all
that would go, if one only would choose "the right tool".

You introduced the msg-loop "thread-topic" without any need,
just to be able to "throw in" the "BackGround-Worker"
terms and whatnot...

A message-loop is without problems hostable in a
Sub Main(), directly in VBs default-main-thread.
No need to start an "extra-thread" for that.

That's why I mentioned Sergeys code, which does
exactly that (a "Timer-Intervalled" messageloop in
Sub Main - running on the main-thread, to poll on
Comm-devices or whatever Henning wants to do
there in his service) - having only the "Service-Manager-
messaging-calls" running on their own thread (triggered
per CreateThread-API, internally using Typlib-Calls in
the Threads Callback.routine).

> > Somewhat sad BTW, that you don't even try -
> > to stay true to your own words (posted only a
> > few days ago) - to not pester the group with
> > ".NET-suggestions" anymore.
> >
> I have not suggested .NET at all.
Sure, /rolleyes/ ... you mentioned no Background-Workers,
no C#, no .NET. - nothing ... <g>

Instead you tried, to post VBClassic-Code?
You offered Links to VB-Classic-Code?

> I'm not sure where you got that impression -
> but I suggest you go back and re-read what I said.
You want to fool me know, do you?

> Yes, I mentioned .NET -
??? Oh...

> but, not in the context of suggesting the OP switch or
> use it... Just to implement something similar.
So that is your new tactics now?
Suggestions on how one would implement "something similar"
over "there"?

Sorry, but that's the same marketing-bullshit as always!
If you are not experienced enough in VBclassic, to
suggest VBclassic-based solutions, then please
stay away from posting stuff which is using different
languages or platforms. They are of no use here,
thank you.
If you "need that" somehow, then why not post such
offtopic solutions "just for a change" e.g. in the delphi-
groups for a while? 'm sure they will love you there too.

Olaf


From: Schmidt on 1 Jun 2010 15:30

"Henning" <computer_hero(a)coldmail.com> schrieb im Newsbeitrag
news:hu3lbr$to0$1(a)news.eternal-september.org...

> The Timers are running ok now, without any this or that, just
> SetTimer/KillTimer.
Yep - works too.

> Next up is using mscomm32.ocx directly from code by
> reference. I know I read somewhere that someone had
> a .dll replacing the .ocx, but hasn't found it again...yet.
IMO the suggestion was, to look up on Planetsourcecode,
for a near "full blown" implementation, not sure though.

If this helps you (and if your device requires only simple
communication - without any DTR-stuff and things like
that) - this is what we use here on small 3.5" embedded
AtomCPU-PC-boards, running linux/wine+a small VB-App
"on top", to talk to "machines" over Rs232:


'***Into a VB-Class:
'Original code by Darren Richards... only slightly adapted

Option Explicit

Private Type DCB
DCBlength As Long
BaudRate As Long
fdwFlags As Long
wReserved1 As Integer
XonLim As Integer
XoffLim As Integer
ByteSize As Byte
Parity As Byte
StopBits As Byte
XonChar As Byte
XoffChar As Byte
ErrorChar As Byte
EofChar As Byte
EvtChar As Byte
wReserved2 As Integer
End Type

Private Type COMMTIMEOUTS
ReadIntervalTimeout As Long
ReadTotalTimeoutMultiplier As Long
ReadTotalTimeoutConstant As Long
WriteTotalTimeoutMultiplier As Long
WriteTotalTimeoutConstant As Long
End Type

Private Type COMSTAT
fCtsHold As Long
fDsrHold As Long
fRlsdHold As Long
fXoffHold As Long
fXoffSent As Long
fEof As Long
fTxim As Long
fReserved As Long
cbInQue As Long
cbOutQue As Long
End Type

' kernel defined constants
'

Private Const OPEN_EXISTING& = 3&
Private Const GENERIC_READ& = &H80000000
Private Const GENERIC_WRITE& = &H40000000
Private Const INVALID_HANDLE_VALUE& = -1 '&HFFFF&
Private Const MAXDWORD& = -1 '&HFFFF&

' comms Constants
'

Private Const PURGE_TXCLEAR = &H4
Private Const PURGE_RXCLEAR = &H8

Private Const CE_RXOVER = &H1 ' Receive Queue overflow
Private Const CE_OVERRUN = &H2 ' Receive Overrun Error
Private Const CE_RXPARITY = &H4 ' Receive Parity Error
Private Const CE_FRAME = &H8 ' Receive Framing error
Private Const CE_BREAK = &H10 ' Break Detected
Private Const CE_TXFULL = &H100 ' TX Queue is full

Private Const SETRTS = 3 ' Set RTS high
Private Const SETDTR = 5 ' Set DTR high

Private Declare Function CreateFile Lib "kernel32" Alias "CreateFileA"
(ByVal _
lpFileName As String, ByVal dwDesiredAccess As Long, ByVal dwShareMode
As _
Long, ByVal lpSecurityAttributes As Long, ByVal dwCreationDisposition As
_
Long, ByVal dwFlagsAndAttributes As Long, ByVal hTemplateFile As Long)
As Long

Private Declare Function CloseHandle Lib "kernel32" (ByVal hObject As Long)
As Long
Private Declare Function GetLastError Lib "kernel32" () As Long
Private Declare Function WriteFile Lib "kernel32" (ByVal hFile As Long,
lpBuffer As _
Any, ByVal nNumberOfBytesToWrite As Long, lpNumberOfBytesWritten As
Long, _
ByVal lpOverlapped As Long) As Long
Private Declare Function ReadFile Lib "kernel32" (ByVal hFile As Long,
lpBuffer As _
Any, ByVal nNumberOfBytesToRead As Long, lpNumberOfBytesRead As Long,
ByVal _
lpOverlapped As Long) As Long
Private Declare Function SetCommState Lib "kernel32" (ByVal hCommDev As
Long, lpDCB _
As DCB) As Long
Private Declare Function SetCommTimeouts Lib "kernel32" (ByVal hFile As
Long, _
lpCommTimeouts As COMMTIMEOUTS) As Long
Private Declare Function PurgeComm Lib "kernel32" (ByVal hFile As Long,
ByVal _
dwFlags As Long) As Long
Private Declare Function BuildCommDCB Lib "kernel32" Alias "BuildCommDCBA"
(ByVal _
lpDef As String, lpDCB As DCB) As Long
Private Declare Function SetCommMask Lib "kernel32" (ByVal hFile As Long,
ByVal _
dwEvtMask As Long) As Long
Private Declare Function ClearCommError Lib "kernel32" (ByVal hFile As Long,
_
lpErrors As Long, lpStat As COMSTAT) As Long
Private Declare Function SetupComm Lib "kernel32" (ByVal hFile As Long,
ByVal _
dwInQueue As Long, ByVal dwOutQueue As Long) As Long
Private Declare Function EscapeCommFunction Lib "kernel32" (ByVal nCid As
Long, _
ByVal nFunc As Long) As Long
Private Declare Function GetCommMask Lib "kernel32" (ByVal hFile As Long,
lpEvtMask _
As Long) As Long
Private Declare Function GetCommModemStatus Lib "kernel32" (ByVal hFile As
Long, _
lpModemStat As Long) As Long
Private Declare Function WaitCommEvent Lib "kernel32" (ByVal hFile As Long,
_
lpEvtMask As Long, ByVal lpOverlapped As Long) As Long


'########################
Private hPort&

Public Property Get PortHdl&()
PortHdl = hPort
End Property

' Gibt PortHandle zur�ck
Public Function OpenComPort(ByVal strPortName As String, _
Optional ByVal strSettings As String = "9600,N,8,1") As Boolean
Dim tCto As COMMTIMEOUTS
Dim tDcb As DCB


tDcb.DCBlength = Len(tDcb)
Call BuildCommDCB(strSettings, tDcb)

hPort = CreateFile(strPortName, GENERIC_READ + GENERIC_WRITE, _
0, 0, OPEN_EXISTING, 0, 0)

If hPort = INVALID_HANDLE_VALUE Then

Dim lErr As Long
lErr = GetLastError()
'fOmegaServer.Caption = "Failed to open comport( err = " & CStr(lErr)
& ")"
Exit Function
Else


Call SetCommState(hPort, tDcb)
Call SetupComm(hPort, 64000, 64000) ' hPort, InQue, OutQue


tCto.ReadIntervalTimeout = MAXDWORD ' return with whatever is
available
tCto.ReadTotalTimeoutMultiplier = 0
tCto.ReadTotalTimeoutConstant = 0

tCto.WriteTotalTimeoutMultiplier = 0
tCto.WriteTotalTimeoutConstant = 10000 ' max 10 secs to write data,
'' just to stop locking up application if we go wrong
Call SetCommTimeouts(hPort, tCto)

Call EscapeCommFunction(hPort, SETDTR)
Call EscapeCommFunction(hPort, SETRTS)

End If

OpenComPort = True

End Function


' Schreibt ByteArray auf COM-Port - gibt cbWritten
Public Function WriteComPort(lpData As Long, ByVal cbData As Long) As Long
Dim fWrite As Boolean
Dim cbWritten As Long
If hPort = 0 Or hPort = -1 Then Exit Function
fWrite = WriteFile(hPort, ByVal lpData, cbData, cbWritten, 0)

If Not fWrite Then

Dim lErr As Long
lErr = GetLastError()
Debug.Print "WriteFile failed ( err = " & CStr(lErr) & " )"

' make sure any comms errors are cleared
Dim tComStat As COMSTAT
Dim lErrFlags As Long

Call ClearCommError(hPort, lErrFlags, tComStat)
Call handleCommError(hPort, lErrFlags)

End If

WriteComPort = cbWritten
End Function


' Liest ByteArray vom COM-Port - gibt cbRead
Public Function ReadComPort(lpData As Long, ByVal cbData As Long) As Long
Dim fRead As Boolean, cbRead&
If hPort = 0 Or hPort = -1 Then Exit Function

fRead = ReadFile(hPort, ByVal lpData, cbData, cbRead, 0)

If Not fRead Then

Dim lErr As Long
lErr = GetLastError()
'fOmegaServer.Caption = "ReadFile failed ( err = " & CStr(lErr) & " )"

' make sure any comms errors are cleared
Dim tComStat As COMSTAT
Dim lErrFlags As Long

Call ClearCommError(hPort, lErrFlags, tComStat)
Call handleCommError(hPort, lErrFlags)

End If

ReadComPort = cbRead
End Function

Public Sub CloseComPort()
If hPort = 0 Or hPort = -1 Then Exit Sub

Call PurgeComm(hPort, PURGE_TXCLEAR Or PURGE_RXCLEAR)
Call CloseHandle(hPort)
hPort = INVALID_HANDLE_VALUE
End Sub


Public Sub StatComPort(lRxBuffer As Long, lTxBuffer As Long)

Dim tComStat As COMSTAT
Dim lDummy As Long
If hPort = 0 Or hPort = -1 Then Exit Sub


Call ClearCommError(hPort, lDummy, tComStat)

lRxBuffer = tComStat.cbInQue
lTxBuffer = tComStat.cbOutQue

End Sub


Private Sub handleCommError(lPortHandle As Long, lErrMask As Long)

If (lErrMask And CE_RXOVER) Then
Debug.Print "Receive overrun detected on com port"
Call PurgeComm(lPortHandle, PURGE_RXCLEAR)
End If
If (lErrMask And CE_OVERRUN) Then
Debug.Print "Byte lost on com port by hardware"
End If
If (lErrMask And CE_RXPARITY) Then
Debug.Print "Parity error detected on com port"
End If
If (lErrMask And CE_FRAME) Then
Debug.Print "Framing error detected on com port"
End If
If (lErrMask And CE_BREAK) Then
Debug.Print "Break condition detected on com port"
End If
If (lErrMask And CE_TXFULL) Then
Debug.Print "Transmit buffer overflow detected"
Call PurgeComm(lPortHandle, PURGE_TXCLEAR)
End If

End Sub

Private Sub Class_Terminate()
CloseComPort
End Sub


Olaf



From: Tom Shelton on 1 Jun 2010 16:02
Schmidt was thinking very hard :
> "Tom Shelton" <tom_shelton(a)comcast.invalid> schrieb im Newsbeitrag
> news:hu380f$5kf$1(a)news.eternal-september.org...
>> Schmidt presented the following explanation :
>
>> I know that. That's not the question. I was talking about
>> the Unattended execution project option...
> This option is more a "compile-time"-option -
> which supresses e.g. MsgBoxes (even if those are
> coded and called in such a Project) from popping-up.
> Standard-VB-Forms are not allowed to define there.
>
> Timer-Controls (which need a VB-Form or Usercontrol
> as a Container) can be replaced with one of the
> class-based Timers which are available "all over the Web".
> For example this one here works pretty well:
> http://www.vbforums.com/showthread.php?p=3790920
>
> Also the CreateWindowEx-APIs (to create your
> own windows, if you need them for example for
> your own class-implementation of the Winsock-API)
> do work without problems, even when Unattended
> Execution was switched on (even when running under
> the system-account as a service later on).
>
>> I realize you can create threads in a standard exe.
>> But since we were not even talking about the example
>> you posted further down the thread,
>> I'm not sure why you bring this up here.
> Because you said:
> "You can use SetTimer/KillTimer has has already
> been suggested - but you still need a message loop.
> Because of that you will probably want to wrap
> it in an object that is on a background thread"...
> ...
> Followed by your usual "suggestions" - how easy all
> that would go, if one only would choose "the right tool".
>
> You introduced the msg-loop "thread-topic" without any need,
> just to be able to "throw in" the "BackGround-Worker"
> terms and whatnot...
>
> A message-loop is without problems hostable in a
> Sub Main(), directly in VBs default-main-thread.
> No need to start an "extra-thread" for that.
>
> That's why I mentioned Sergeys code, which does
> exactly that (a "Timer-Intervalled" messageloop in
> Sub Main - running on the main-thread, to poll on
> Comm-devices or whatever Henning wants to do
> there in his service) - having only the "Service-Manager-
> messaging-calls" running on their own thread (triggered
> per CreateThread-API, internally using Typlib-Calls in
> the Threads Callback.routine).
>
>>> Somewhat sad BTW, that you don't even try -
>>> to stay true to your own words (posted only a
>>> few days ago) - to not pester the group with
>>> ".NET-suggestions" anymore.
>>>
>> I have not suggested .NET at all.
> Sure, /rolleyes/ ... you mentioned no Background-Workers,
> no C#, no .NET. - nothing ... <g>
>
> Instead you tried, to post VBClassic-Code?
> You offered Links to VB-Classic-Code?
>
>> I'm not sure where you got that impression -
>> but I suggest you go back and re-read what I said.
> You want to fool me know, do you?
>
>> Yes, I mentioned .NET -
> ??? Oh...
>
>> but, not in the context of suggesting the OP switch or
>> use it... Just to implement something similar.
> So that is your new tactics now?
> Suggestions on how one would implement "something similar"
> over "there"?
>
> Sorry, but that's the same marketing-bullshit as always!
> If you are not experienced enough in VBclassic, to
> suggest VBclassic-based solutions, then please
> stay away from posting stuff which is using different
> languages or platforms. They are of no use here,
> thank you.
> If you "need that" somehow, then why not post such
> offtopic solutions "just for a change" e.g. in the delphi-
> groups for a while? 'm sure they will love you there too.
>
> Olaf

I was going to respond point-by-point, but this is just becomming
rediculous. You are reading stuff into my reply that was never
intended. I only suggested using his timer on a background thread
(using standard ax exe threading - I never mentioned anything about
background workers - because I assumed this was an activex exe) because
I was unaware that the nt service ocx thingy did that for you. It's
not something I had ever tried. Even when I did VB.CLASSIC, I still
wrote services in C++ because the ocx was generally considerd unstable.

As for the rest, simply mentioning C# or .NET is in not even close to
the samething as advocating them. Do you never look at other language
or library implementations to figure out a better way to accomplish a
task? All of my suggestions at the heart were to create vb classes
wrapping windows api functions - and possibly making use of ax
threading if needed.

I know you are smart guy - I have read enough of your posts to know
that and I respect that - that's why I have even attempted to respond
to you. But, you need to chill - this whole freaking out at the mere
mention of .net thing is becomming quite borish. I can understand it
from a foul mouthed, imbicile such as Kevin - but, not so much from
you.

--
Tom Shelton


From: Schmidt on 1 Jun 2010 17:12

"Tom Shelton" <tom_shelton(a)comcast.invalid> schrieb im Newsbeitrag
news:hu3p14$ftv$1(a)news.eternal-september.org...

> I was going to respond point-by-point, but this is
> just becomming rediculous.
Yep.

> You are reading stuff into my reply ...
As you say, ridiculous...

You already statet yourself (some time ago),
that you do not use VBclassic anymore - so why do
you *post* here at all (nothing against "silent lurking"),
if all you have to offer for users who *do use*
Vbclassic is: "how one could implement the
same thing in a different language" - that's just not
sufficient, and it's off-topic, sorry.

Olaf


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Thanks to all contributors & results
Next: How can I implement jagged arrays in VB6? UDT?