Is DDT slow?

[Lance Edmonds]

John, maybe you have misread or misinterpreted my message...?

To be clear, ON ERROR RESUME NEXT and ON ERROR GOTO 0 both produce the same results... they disable the error handler (if one exists).

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[John Kovacich]

Fred, to disable error checking don't you need to use
On error goto 0?

Lance, I'm not sure I would call on error resume next safer, since
any called subroutine or function would carry over this and may not
tip you off when you have an error. However, I do use it personally,
but I set on error goto 0 for critical sections, especially while I'm
debugging.

------------------
Thanks,

John Kovacich

[Fred Oxenby]

Originally posted by Borje Hagsten:
A small question on "ON ERROR RESUME NEXT": I have been under the impression that
using "IF ERR THEN.." after critical parts in code is a bit faster/leaner and even
a bit "safer". Is it just something I have dreamt? I sometimes tend to mix things up..

Old habbits die hard
I tend to start all SUB/FUNCTIONS with disabling error-trapping = ON ERROR RESUME NEXT.
(This is only to visualize to me and other reading the code that there are only error-handling
where explit done so with IF ERR(CLEAR) THEN ..)
Then I use ErrClear to clear the ERR-variable before I code an instruction that will be
checked for error. Theoretical this could mean that my code is prune to GPF-s.
Errors when opening a file has one type of recovery, when writing or reading another, so I
find it more efficient to handle errors where it occure (in code), even if this mean that
I repeat the same code over and over again.
I have considered this approach:

Function SomeFunction()as long
  On Error GoTo Errhandler
  .....
  Errclear:Open File$ for binary as #1
  If ErrClear > 0 Then 
  ...
  ...
Errhandler:
  Resume next
End Function

But that does not work in PB as RESUME need a label. And RESUME resets the ERR-variable (I think)


------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se



[This message has been edited by Fred Oxenby (edited March 19, 2001).]

[Fred Oxenby]

Originally posted by Paul Dwyer:
Fred,
Question slightly off topic, I notice you code contains chars outside the ASCII set (ie, in the 128 and above ANSII set)
have you noticed any problems with DDT using these sorts of strings?

"MS Sans Serif" and "Helv" cannot correctly display double-byte strings. Therefore, under a DBCS-enabled system,
dialog boxes need to use the system font instead.
I dont know if you have tried this...
Otherwise, as this thread is a living proof, I do not use DDT much
The swedish "national characters" have been arond since 1980 in a standard way (Dos PCU10)
and I have learned to only use proven fonts. In the Anglo-word people still
live in the 7-byte ascii-world (I suppose they still use tele-type), rest of the word turned to
the 8-bit ascii in the 1980-s
The only advice I can give is to check what "picture" is assingned to characters
obove 127

------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[Borje Hagsten]

Hm, yes, but then again, since PB already produces such lean code, that
is not a big deal. What I meant by "safer" is that many programmers tend
to use ON ERROR RESUME NEXT, without doing anything more.

This can lead to disaster, if the error for example has caused a stop
variable to remain blank before entering a loop, etc. Like Lance says,
it's a personal taste. I just happen to like IF ERR THEN after critical
points better..


------------------


[This message has been edited by Borje Hagsten (edited March 19, 2001).]

[Bern Ertl]

This thread is splitting into different directions, but I wanted
to clarify something Borje touched on earlier regarding error
handling.

If one uses ON ERROR GOTO/GOSUB the compiler necessarily adds
error checking code after every PB statement, doesn't it? Whereas
using IF ERR THEN whenever one suspects error possibilities does not
force the compiler to add such error checking throughout the code
(section).

Therefore, Borje's original assertion about LEANER code using
IF ERR vs. ON ERR is correct, isn't it? I wouldn't begin to imagine
that it is "SAFER" - too many variables to make such a claim...

------------------
Bernard Ertl

[This message has been edited by Bern Ertl (edited March 19, 2001).]

[Paul Dwyer]

Fred,

Question slightly off topic, I notice you code contains chars outside the ASCII set (ie, in the 128 and above ANSII set)
have you noticed any problems with DDT using these sorts of strings?

Forget the unicode issues obviously, I have had a lot of problems using the over 127 char set because of font issues and I'm wondering if you've had them too...

eg, I pass a label set to system font text like "“ú–{Œê‚̃eƒLƒXƒg"@and it's fine but in the dialog caption it's garbage, even if wrtten, compiled and run on the desired OS...

Comments are very welcome because I've overcome these issue with unicode but not on the native 98 and ME systems... (Hate thoses OS's)



------------------
Paul Dwyer
Network Engineer
Aussie in Tokyo

[Lance Edmonds]

Originally posted by Chris Boss:
Lance;
Fred is not talking about EZGUI (the GUI engine), but he is using
my freeware DDT Visual Designer (which is pure DDT and no runtime)
so his problem is with DDT and not EZGUI (since he isn't using EZGUI).

Ok, we'll accept your retraction... the problem is NOT DDT!




------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Chris Boss]

Fred;

I had a strong feeling it was something else that was being
overlooked !

For those of you who are "lurking":

While it is true the Windows Dialog engine (which affects DDT and
EZGUI 1.0) does have more overhead than using CreateWindow (SDK), the
difference in speed between the two should be negligable !

Whether you use SDK, DDT, EZGUI or the Windows Dialog Engine directly,
the major slow down in Dialog display will be the graphic nature of
Windows and higher resolutions used by Video adapters today,

Most Dialog engines (ie. DDT, EZGUI) use very little code to do what
they do and most of that code is just a few Integer calculations. We are
talking about milliseconds here. The Video adapter on the other hand
must have thousands to millions of bytes moved around for every single
tiny modification of the screen. Compared to DOS, Windows major slow down
is the Video adapter and all the work it has to do. With the high speeds
of CPUs today the calculations made by Dialogs is insignificant. It is
the video adapter manipulation that is the hog.

ie.

In a DOS text screen, you could change an entire text screen by poking 2000 bytes
(2 KB) to the video adapter. To change a single line of text would only require
160 bytes.

Now, in a Windows app, most computers are running high resolutions.

For example an 800 x 600 resolution using 24 bit color requires
1,440,000 bytes (1.4 Meg) to be moved for a single screen update.

A single line of text (comparable to a single line in DOS) would be
57,600 bytes (57 KB). Now with Windows, screen pixels are not just
simply poked into Video Ram. Windows uses complex Device contexts
to control writing to Video ram. It uses clipping and other stuff that
produces a huge overhead in simply writing data to the Video adapter.

This means that conceivably Windows can take as much a 1000 to 5000 times
(any maybe more) longer to update screen data as DOS. If Windows could simply poke
data into video ram, it would take 720 times as long as DOS to update
a single screen.

Simply put, if you are having problems with speed of updating a Dialog
the overhead of DDT or the Windows Dialog engine (or even EZGUI) is
simply negligable compared to suchs things as writing data to the
Video adapter which all apps have to do (through Windows of course).

Fred's case was obviously one dealing with disk access (which is slow
too).

The moral of the story :

If your Dialogs seems sluggish in updating data, then first look at
how much data you are actually trying to push onto the screen and how
fast and remember the graphic nature of Windows slows things down
terribly.

Second, look for errors in your algorythms or disk access code and
look for bottlenecks there.

Fred;

I am glad you finally found your problem !

And No you aren't stupid !

I don't know how many times I have felt like a dog chasing his tail
trying to fix a bug, only to find it was some very simple error.

A good programmer is not one who never make a mistake. He is one who
has made plenty of mistakes , but has learned a number of lessons
from those mistakes.




------------------

[Chris Boss]

Lance;

Fred is not talking about EZGUI (the GUI engine), but he is using
my freeware DDT Visual Designer (which is pure DDT and no runtime)
so his problem is with DDT and not EZGUI (since he isn't using EZGUI).

EZGUI 1.0 uses Form name strings, while the code generated with my
DDT Visual Designer uses standard handles required by DDT.

Fred;

I believe you own a copy of EZGUI 1.0 !

Have you tried using it, just for a test, to see if it is slow too ?

I would suggest trying to use EZGUI 1.0 (just as a test) to see if
the dialogs are slowing things down. EZGUI should have slightly more
overhead that DDT would, so I would expect it to be very slow if
you think DDT is very slow. EZGUI 1.0 uses the Windows Dialog engine
(note 2.0 doesn't use the Windows Dialog engine anymore), so it
should be comparable to DDT.

EZGUI 1.0 has a reasonbly optimized message loop (as long as you don't use
Modal windows), so it would make a good test.

If EZGUI 1.0 is slow too, then the problem likely lies with the
Windows Dialog engine and you will have to do a little searching to
find the bottleneck.

Note: When you use any type of code that depends upon the
Windows Dialog engine, Modal Dialogs will not use the message
loop provided (by DDT or EZGUI 1.0). Modal Dialogs use a message loop
provided by Windows itself and not the message loop in the app itself.



------------------

[Fred Oxenby]

I feel so dumb.
I feel so stupid.
I am the most ignorant programmer in the world.
And I am stupid too.
I am sorry to have occupied your good time with a question like this.
-----
Some of you, perhaps recall a thread about a rotten novell-network,
some month ago.
My customer forced me to implement excessiv retries on file-operations
Like this:

   FilNr& = GetFreeFile()
   Retry& = 0
   Do 
    ErrClear:Open TransIdxDir$ & FilNamn$ For Binary Access Read Lock Shared As FilNr&
    If ErrClear = 0 Then Function = %True:Exit Do
    If Retry& > 5   Then Function = %False:GoTo ErrExit
    Incr Retry&:Sleep 50
   Loop

And I used an old app (without retries) to compare with (have I said I am stupid)
In my development-environment I do not have production-database so
all seeks there took 2*250 ms for every entry as all lookups failed.
After simply removing the database-lookup reading all loggfile/updating
the listbox took only 16 seconds, and DDT-engine had no problem to keep
up with incomming messages.

2 days of completly wasted time, mine and yours.
sorry


------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[Lance Edmonds]

Originally posted by Borje Hagsten:
A small question on "ON ERROR RESUME NEXT": I have been under the impression that
using "IF ERR THEN.." after critical parts in code is a bit faster/leaner and even
a bit "safer". Is it just something I have dreamt? I sometimes tend to mix things up.

As compared to ON ERROR GOTO?

Using ON ERROR RESUME NEXT (the default) is perfectly "safe" as long as you carefully write your code to trap all possible errors (or at least the crippling ones!), whereas using ON ERROR GOTO is "guaranteed" to trigger on all runtime errors (except GPF's, etc!).

Really it comes down to coding style (personal preference) and the task at hand, for the choice of which error detection scheme you employ in each sub/function in your code.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Fred Oxenby]

Originally posted by Lance Edmonds:
Fred, no offence to Chris and yourself, but my understanding is that EZGUI uses strings to identify controls, etc, so without seeing this code and whether is uses Chris's DLL's functions to update the controls, we can't confirm the facts of your statement.
Can you post the code for review too please? Thanks!

This is the complete test program

#Compile Exe "EXE\MASTXX.EXE"
#Register None
#Dim All
 %NOANIMATE    = 1
 %NOBUTTON     = 1
 %NOCOMBO      = 1
 %NODRAGLIST   = 1
 %NOHEADER     = 1
 %NOIMAGELIST  = 1
 %NOLIST       = 1
 %NOLISTVIEW   = 1
 %NOSTATUSBAR  = 1
 %NOTABCONTROL = 1
 %NOTOOLBAR    = 1
 %NOTOOLTIPS   = 1
 %NOTRACKBAR   = 1
 %NOTREEVIEW   = 1
 %NOUPDOWN     = 1
#Include "\!INCLUDE\WIN32API\WIN32API.INC"
#Include "\!INCLUDE\WIN32API\COMMCTRL.INC"
#Include "\!INCLUDE\DECLARES\FOXRUN32.INC"
%LISTBOX            = 100
%BUTTON1            = 105
' --------------------------------------------------
Declare CallBack Function Form1_DLGPROC
Declare CallBack Function CBF_BUTTON1
'--Tråd-Status UDT-s-----------------------------
Global udtProd  As Typ_ThreadStatus
Global hForm1&    ' Dialog handle

Global gDisk           As String
Global gMasterDir      As String
Global gMasterId       As Long
Global glbAbort        As Long

Function PbMain
Local Count&
Local CC1 As INIT_COMMON_CONTROLSEX

  CC1.dwSize=SizeOf(CC1)
  CC1.dwICC=%ICC_WIN95_CLASSES
  InitCommonControlsEX CC1
  Local Style&, ExStyle&
  Style& = %WS_POPUP Or %DS_MODALFRAME Or %WS_CAPTION Or %WS_MINIMIZEBOX Or %WS_SYSMENU Or %DS_CENTER
  ExStyle& = 0
  Dialog New %Hwnd_Desktop, "Your Dialog", 0, 0,  448,  177, Style&, ExStyle& To hForm1&
Dim LList(0) As String
  Control Add ListBox, hForm1&,  %LISTBOX, LList(), 0, 2, 448, 150, _
    %WS_CHILD Or %WS_VISIBLE Or %LBS_NOTIFY Or %LBS_SORT Or %LBS_NOINTEGRALHEIGHT Or %WS_VSCROLL Or %WS_TABSTOP, _
    %WS_EX_CLIENTEDGE
  Control Send hForm1&,  %LISTBOX, %WM_SETFONT,GetStockObject(%ANSI_FIXED_FONT), %TRUE
  Control Add "Button", hForm1&,  %BUTTON1,  "Button  1", 176, 158, 53, 15, _
    %WS_CHILD Or %WS_VISIBLE Or %BS_PUSHBUTTON Or %WS_TABSTOP Call CBF_BUTTON1

  Call RUNTIME_INIT(20,"\\NTSERVER\DATA\SPIDER\MASTER20")
  Dialog Show Modeless hForm1& , Call Form1_DLGPROC
  Do
    Dialog DoEvents To Count&
  Loop Until Count&=0
End Function

CallBack Function Form1_DLGPROC
  Select Case CbMsg
    ' Common Windows Messages you may want to process
    ' -----------------------------------------------
    Case %WM_TIMER
    Case %WM_HSCROLL
    Case %WM_VSCROLL
    Case %WM_SIZE
    Case %WM_CLOSE
    Case %WM_DESTROY
    Case %WM_SYSCOMMAND
    Case %WM_PAINT
    ' -----------------------------------------------
    Case %WM_CTLCOLORMSGBOX , %WM_CTLCOLORBTN, %WM_CTLCOLOREDIT,_
         %WM_CTLCOLORSTATIC, %WM_CTLCOLORSCROLLBAR, %WM_CTLCOLORLISTBOX
      ' Control colors
      Select Case GetDlgCtrlID(CbLparam)
        Case Else
          Function=0
      End Select
    Case %WM_NOTIFY
    Case %WM_COMMAND
    Case Else
  End Select
End Function

CallBack Function CBF_BUTTON1
Local ThreadId&,Test&,Retry&
If CbCtlMsg=%BN_CLICKED Then
'--PROD-----------------
  If udtProd.Running = 0 Then
   udtProd.Id          = 0
   udtProd.Running     = 0
   udtProd.ExitCode    = 0
   udtProd.CBLogg      = CodePtr(MAST_LoggEvent)
   udtProd.CBMaster    = CodePtr(MAST_LoggEvent)
   udtProd.CBError     = CodePtr(MAST_LoggEvent)
   udtProd.CBAlertHold = 0
   udtProd.CBAlertQue  = 0
   udtProd.hWndMaster  = hForm1&
   udtProd.CBStatus    = 0 'CodePtr(SetIndicator)
   Thread Create Prodscan(VarPtr(udtProd)) To ThreadId&
  End If
End If
End Function

Function MAST_LoggEvent(LM As LogMsg_Typ) As Long
Local Datum$,Msg$,UtMsg$,ListCount&,Li&,chkStatus&
Local Nu As Double
  On Error Resume Next
  Nu = Now()
  Msg$ = Space$(SizeOf(LM))
  Lset Msg$ = LM
  Replace Chr$(0) With Chr$(32) In Msg$
  Msg$ = Rtrim$(Msg$)
'--Formattera meddelandet------------------------
  Datum$ = FormatDateTime(Nu,"YYMMDD HH:MM:SS")
  UtMsg$ = Datum$ & " " & Msg$
  'EnterCriticalSection CS_GateList
'--radera i listan om mer än 10,000 meddelanden--
  Control Send hForm1&,%Listbox,%LB_GETCOUNT,0,0 To ListCount&
  If ListCount& > 10000 Then
   Control Send hForm1&,%Listbox,%WM_SETREDRAW,0&,0&
   For Li& = 1 To 1000
    Control Send hForm1&,%Listbox,%LB_DELETESTRING, 0, 0
   Next
   Control Send hForm1&,%Listbox,%WM_SETREDRAW,1&,0&
  End If
'--lägg ut meddelandet i listan-------------------
  Control Send hForm1&,%Listbox,%LB_ADDSTRING,0,StrPtr(UtMsg$) To ListCount&
  Control Send hForm1&,%Listbox,%LB_SETCURSEL , ListCount&, 0 To Li&
'--så skall det ut till loggfilen-----------------
  Datum$ = FormatDateTime(Nu,"YYYYMMDD HH:MM:SS")
  UtMsg$ = Datum$ & " " & Msg$
  Call LOG_MasterLogg(Msg$)
End Function

Type XfpMsg_Typ
 Datum    As String * 11
 Tid      As String * 9
 DxId     As String * 5
 Rutin    As String * 9
 OrderNr  As String * 9
End Type 
Global ClrXM As XfpMsg_Typ
 
Type XfpRadTyp
 Tid       as string * 9      ' 1,9
 Datum     as string * 11     '10,11
 Rutin     as string * 7      '21,7
 x1        as string * 2      '28,2
 DxOrginal as string * 7      '30,7
 DxPages   as string * 9      '37,9
 Unknown   as string * 9      '46,9
 DxCopies  as string * 6      '55,6
 x2        as string * 4      '61,4
 DxId      as string * 5      '65,5
 DxMag     as string * 4      '70,4
 x3        as string * 25     '74,25
 DxFil     as string * 15     '99,15
 DxOrder   as string * 8      '114,8
 x4        as string * 8      '122,8
End type                      '
Declare Function proto_loggevent(LM As logMsg_Typ)As Long

Function XFP_ReadLogg(ByVal Fil$,udt&) As Long
Dim dbLog  As LogInfo
Local yy%,mm%,dd%,hh%,mi%,ss%
Local FilNr&,InRad$,Sync$
Local glbCB_Logg As DWord  
Local pUdt As Typ_ThreadStatus Ptr
  pUdt = udt&
  glbCB_Logg = @pudt.CBLogg

'..Öppna filen i Binary mode.........................................
   On Error Resume Next
   If FSO_FileExists(Fil$) = 0 Then Function = 100: GoTo ErrExit
   FilNr& = GetFreeFile
   ErrClear:Open Fil$ For Binary Access Read Shared As FilNr&
   If ErrClear > 0 Then Function = 100: GoTo ErrExit
'..Läs in filens sync................................................
   dbLog.FilNamn = Fil$
   ErrClear:Get FilNr&,1, dbLog.Sync
   If ErrClear > 0 Then Close FilNr&: Function = 101: GoTo ErrExit
   Close FilNr&
'..Hämta Logginfo-posten.............................................
   If DBLOG_GetInfo(Fil$, ByCopy dbLog.Sync, dbLog) = %False Then Function = 102: GoTo ErrExit
'..Öppna filen i Shared mode.........................................
   ErrClear:Open Fil$ For Input Lock Shared As FilNr& 
   If ErrClear > 0 Then Function = 100: GoTo ErrExit
   If dbLog.FilePos >= Lof(FilNr&) Then Close FilNr&: Function = %True: GoTo ErrExit
'..Gå till sista läsposition.........................................
   ErrClear:Seek FilNr&, dbLog.FilePos
'..loopa genom filen till slutet.....................................
Local XR As XfpRadTyp
   Do While Not Eof(FilNr&)
    Sleep 0
    If glbAbort <> 0 Then
     Call DBLOG_SaveInfo(dbLog)
     Close FilNr&:Function = 200:Exit Function
    End If
    ErrClear:Line Input #FilNr&,InRad$
    If ErrClear > 0 Then Close FilNr&: Function = 101: GoTo ErrExit
    dbLog.FilePos = Seek(FilNr&)
    LSet XR = UCase$(InRad$)
    If Instr(XR.DxFil, "OFFLINE") > 0 Then Iterate Do
    If (Instr(XR.DxMag, "X")> 0) And _
       (Len(RTrim$(XR.DxFil,any Chr$(0,32)))> 0) Then GoSub NyttXFPEntry
   Loop
'..Filslut så uppdatera FilPos och stäng filen.......................
   ErrClear:dbLog.FilePos = Seek(FilNr&)
   Call DBLOG_SaveInfo(dbLog)
   Close FilNr&
   Function = 0
ErrExit:
   Exit Function

'--SUBRUTIN----------------------------------------------------------
NyttXFPEntry:
   Replace any "./-" With "---" In XR.Datum
   Replace any "./-" With ":::" In XR.Tid
'--LoggDatum-------------------------------------
    yy% = Val(Parse$(XR.Datum,"-",1))
    mm% = Val(Parse$(XR.Datum,"-",2))
    dd% = Val(Parse$(XR.Datum,"-",3))
    dbLog.LogDate = VbDateSerial(yy%,mm%,dd%)
'--LoggTid---------------------------------------
    hh% = Val(Parse$(XR.Tid,":",1))
    mi% = Val(Parse$(XR.Tid,":",2))
    ss% = Val(Parse$(XR.Tid,":",3))
    dbLog.LogTime = VbTimeSerial(hh%,mi%,ss%)
'--Spara entryt----------------------------------
   Call DBLOG_SaveInfo(dbLog)
'--hämta transaktionen---------------------------
Dim T As UtCmdTyp
Local LM As LogMsg_Typ,XM As XfpMsg_Typ
Local TransNr$,TransIdx$
   LSet LM = Space$(400)
   LSet XM = Space$(400)
   TransNr$ = Trim$(XR.DxFil,any Chr$(0,32))
   TransIdx$ = TransNr$
   LM.Modul = "XFPLOG"
   LM.Funktion = "NY POST"
   LM.FilNamn = TransIdx$
   XM.Datum   = RTrim$(XR.Datum,any Chr$(0,32))
   XM.Tid     = RTrim$(XR.Tid,any Chr$(0,32))
   XM.DxId    = RTrim$(XR.DxId,any Chr$(0,32))
   XM.Rutin   = RTrim$(XR.Rutin,any Chr$(0,32))
   XM.OrderNr = Format$(Val(XR.DxOrder),"0000000")
   
   If IsFalse TRANS_GetRecord(TransNr$,T) Then
    If IsFalse TRANS_FindTrans(TransIdx$,T) Then
     LSet LM.Text = XM & "*VARNING* Kan inte finna transaktionen"
'SendMessage hWnd_Master,%LOG_PROD,ByVal VarPtr(LM),0
     If glbCB_Logg <> 0 Then Call DWord glbCB_Logg Using proto_LoggEvent(LM)
     Return
    End If
   End If
'--Skapa index-----------------------------------
Local Tidx As TransIdxTyp,Tmp$
   TransNr$ = RTrim$(T.TransNr,any Chr$(0,32))
   TIdx.TransNr = T.TransNr
   TIdx.FilNamn = T.FilNamn
'--skapa meddelande------------------------------
   LM.Funktion = "NY POST "
   LM.TransNr = TransNr$
   Tmp$ = FSO_GetBaseName(RTrim$(T.InFil,any Chr$(0,32)))
   If Len(Tmp$) > 8 Then Tmp$ = Mid$(Tmp$,1,8)
   Tmp$ = Tmp$ & "." & FSO_GetExtensionName(RTrim$(T.InFil,any Chr$(0,32)))
   LM.FilNamn = Tmp$
'--Uppdatera transaktionen------------------------
   T.ProdDatum = dbLog.LogDate
   T.ProdTid   = dbLog.LogTime
   T.PrintId   = XR.DxId
   If Val(XR.DxOrder) > 0 Then T.OrderNr = Val(XR.DxOrder)
   T.DXRutin   = XR.Rutin
   T.DXOrginal = Val(XR.DXOrginal)
   T.DXPages   = Val(XR.DXPages)
   T.DXCopies  = Val(XR.DXCopies)
'--Uppdatera transaktionen------------------------
   If IsFalse TRANS_UpDateRecord(T) Then
    LSet LM.Text  = XM & " *ERROR* Kan inte uppdatera transaktionen"
'SendMessage hWnd_Master,%LOG_PROD,ByVal VarPtr(LM),0
    If glbCB_Logg <> 0 Then Call DWord glbCB_Logg Using proto_LoggEvent(LM)
    Return
   End If
'--Alles Ok skapa JobMsg-------------------------
   Call MSG_PCSTvaPost(TransNr$,TIdx)
   LSet LM.Text = XM
'SendMessage hWnd_Master,%LOG_PROD,ByVal VarPtr(LM),0
   If glbCB_Logg <> 0 Then Call DWord glbCB_Logg Using proto_LoggEvent(LM)
   Return
End Function


Function PRODSCAN(ByVal udt&)As Long
Local LM As LogMsg_Typ
Local CB_Master As Dword
Local pUdt As Typ_ThreadStatus Ptr
  pUdt = udt&
  @pudt.ID      = GetCurrentThreadId
  @pudt.Running = 1
  CB_Master    = @pudt.CBMaster
  LM.TransNr  = "--------"
  LM.FilNamn  = "------------"
  LM.Modul    = "PRODLOGG"
  LM.Funktion = "PRGSTART"
  LM.Text     = "Tråden PRODUKTIONS-LOGGAR startar "
  If CB_Master <> 0 Then Call Dword CB_Master Using proto_Loggevent(LM)
  Call Xfp_ReadLogg("\\NTSERVER\DATA\XFPLOG\PRODXFP1.LOG",udt&)
    LM.TransNr  = "--------"
    LM.FilNamn  = "------------"
    LM.Modul    = "PRODLOGG"
    LM.Funktion = "PRGSTOPP"
    LM.Text     = "Tråden PRODUKTIONS-LOGGAR har avslutats "
    If CB_Master <> 0 Then Call Dword CB_Master Using proto_Loggevent(LM)
  @pudt.Running = 0
End Function

------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[Borje Hagsten]

BTW, Lance - I think Stephane refers to some custom controls that
are implemented in Delphi, under a special WIN32-tab. Speed buttons
and Image buttons, etc.

The idea is not bad though. I too would like to see a Winapi32-button
in next PB, which I simply can press to get all api code written for
me, automatically. Or why not even a Code-button, that writes the
whole darn thing by itself..


------------------

[Borje Hagsten]

> BTW, if there are many lines, more effective to use ownerdrawn (to avoid HASSTRINGS)

..and by far most efficient, of course, is to use raw array with Virtual Listbox..

A small question on "ON ERROR RESUME NEXT": I have been under the impression that
using "IF ERR THEN.." after critical parts in code is a bit faster/leaner and even
a bit "safer". Is it just something I have dreamt? I sometimes tend to mix things up..


------------------

[Lance Edmonds]

Originally posted by stephane fonteyne:
Adding more DDT controls like Dialogs, CommonDlg, Win32...

Stephane, this is completely off-topic for this thread - please try to keep discussions within the scope of the topic at hand.

Regarding your "requests", DDT already offers Dialogs, hence it's name (Dynamic Dialog Tools).

Common Dialog functions are already easily available through the encapsulations in the COMDLG32.INC file.

WIN32? I have no idea what you mean by this, since this is a Win32 compiler for 32-bit Windows.



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

Stephane, je bent een onnozel ventje!
Ik dacht dat je eindelijk eens een antwoord ging geven op iemand
zijn vraag, maar nee, weeral een onnozele vraag waarin je meer en meer
features wilt! Ik hoop echt dat ze je van deze forums verwijderen!!
Ik heb deze vraag vroeger reeds gesteld aan de administrator van de
powerbasic en de ez-gui forums maar ze zijn, gelukkig voor jou, geduldiger
dan ikzelf. Ik hoop echt dat dit het laatste is wat ik van je hoor.


En trouwens, ik heb je door kerel. Je zit je voor te doen als een
programmeur (die alsmaar extra features aangaande oop vraagt) maar in
de nederlandstalige nieuwsgroepen zie ik dan postings staan zoals:

--
Ik zoek de beknopte theorie over het Object Georienteerd programmeren
dus eigenlijk de principes en wat het eigenlijk inhoud maar dan wel
erg verstaanbaar.
Ik weet dat er boeken bestaan maar staat veel te ingewikkeld op
--
Ik gebruik nog altijd PowerBasic producten maar begin eerst met
PowerBasic for DOS compilers v3.50 en wordt een vervolg gegeven jawel
en dan met OOP support.
(Ah zo, waar heb je dit opgevangen??)
--
Of wat dacht je van deze uit be.jobs!!!
Programmeren van een groot applicatieprogramma en bètatester in
PowerBasic (1998-2000)
(Beta-tester?????)
--


En ik kan zo nog een tijdje doorgaan.
Ik hoop echt dat je voorgoed 'verdwijnt'
Ik ben je gezever KOTSBEU.

------------------

[Semen Matusovski]

Fred --
below is a bad code. But anyway it works very fast on my PC.
Except final step - when too many elements, dialog dies.
(change n ... To 10000)

   #Compile Exe
   #Dim All
   #Register None
   #Include "WIN32API.INC"

   %ID_LIST1 = 101
   Global hDlg As Long

   Function MyThread (ByVal x As Long) As Long
      Dim n As Long, Txt As String
                      
      For n = 1 To 1000
         Txt = Str$(100000 - n) + Str$(n) + Str$(x)
         ListBox Add hDlg, %ID_LIST1, Txt
         Sleep 1
      Next
      Dialog Send hDlg, %WM_USER + 401, 0, 0
      
   End Function
   CallBack Function DlgProc
      Local i As Long, t2 As Dword, t1 As Dword, hList As Long
      Select Case CbMsg
         Case %WM_INITDIALOG
             Local x As Long
             Local s As Long
             Dim idThread As Long
             hList = GetDlgItem(CbHndl, %ID_LIST1)
             For i = 1 To 10
                Thread Create MyThread(i) To idThread
                Thread Close idThread To idThread
                Sleep 1
             Next
         Case %WM_USER + 401
            Dim h As Static Long
            Incr h: If h = 10 Then MsgBox "Finished"
    

      End Select
   End Function

   Function PbMain
     Local i As Long
     Dialog New 0, "Listbox", , , 200, 100, %WS_CAPTION Or %WS_SYSMENU To hDlg
     Control Add ListBox, hDlg, %ID_LIST1, , 5, 5, 190, 65
     Dialog Show Modal hDlg, Call DlgProc
  End Function

BTW, if there are many lines, more effective to use ownerdrawn (to avoid HASSTRINGS)

               
   #Compile Exe
   #Dim All
   #Register None
   #Include "WIN32API.INC"


   %ID_LIST1 = 101
   %nEl = 10000
   Global arr() As String

   CallBack Function DlgProc
      Local i As Long, t2 As Dword, t1 As Dword, hList As Long
      Select Case CbMsg
         Case %WM_INITDIALOG
            ReDim arr(%nEl - 1)
            For i = 0 To %nEl - 1
               arr(i) = "Item" + Str$(i) + String$(100, "-")
            Next

         Case %WM_COMMAND
            If CbCtl = 102 Then
               t1 = GetTickCount
               Control Handle CbHndl, %ID_LIST1 To hList
               For i = 0 To %nEl - 1
                  SendMessage hList, %LB_ADDSTRING, i, 0
               Next
               SendMessage hList, %LB_SETCURSEL, 3, 0 ' Item 3
               t2 = GetTickCount
               SetWindowText CbHndl, Str$(t2 - t1)
            End If

         Case %WM_DRAWITEM
            Local lpdis As DRAWITEMSTRUCT Ptr
            lpdis = CbLparam
            If @lpdis.itemID = &HFFFFFFFF& Then Exit Function

            If IsFalse(@lpdis.itemState And %ODS_SELECTED) Then
               FillRect @lpdis.hDC, @lpdis.rcItem, GetStockObject(%WHITE_BRUSH)
               SetBkColor @lpdis.hDC, %WHITE
               SetTextColor @lpdis.hDC, %BLACK
            Else
               FillRect @lpdis.hDC, @lpdis.rcItem, GetStockObject(%BLACK_BRUSH)
               SetBkColor @lpdis.hDC, %BLACK
               SetTextColor @lpdis.hDC, %WHITE
            End If
            TextOut @lpdis.hDC, 0, @lpdis.rcItem.ntop, ByVal StrPtr(arr(@lpdis.itemID)), Len(arr(@lpdis.itemID))
            Function = 1: Exit Function
      End Select
   End Function

   Function PbMain
     Local hDlg As Long, i As Long, hList As Long
     Dialog New 0, "Listbox", , , 200, 100, %WS_CAPTION Or %WS_SYSMENU To hDlg
     Control Add ListBox, hDlg, %ID_LIST1, , 5, 5, 190, 65, _
        %WS_CHILD Or %LBS_OWNERDRAWFIXED Or _
        %WS_TABSTOP Or %LBS_DISABLENOSCROLL Or %WS_VSCROLL, %WS_EX_CLIENTEDGE
      Control Add Button, hDlg, 102, "Add", 50, 75, 90, 15
     Dialog Show Modal hDlg, Call DlgProc
  End Function

------------------
E-MAIL: [email protected]



[This message has been edited by Semen Matusovski (edited March 19, 2001).]

Hi R&D

Adding more DDT controls like Dialogs, CommonDlg, Win32...

greets
Stephane

Ps: PowerBasic is very very good and Powerder of VB.
Visual Basic is very slow because I don't used only used
in school
I'm used C++, TASM, Borland Delphi, and PB

greets
Stephane



------------------

[Lance Edmonds]

Fred, no offence to Chris and yourself, but my understanding is that EZGUI uses strings to identify controls, etc, so without seeing this code and whether is uses Chris's DLL's functions to update the controls, we can't confirm the facts of your statement.

Can you post the code for review too please? Thanks!


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>