CurrentDir() with solution code

Amiga5k · Post by **Amiga5k** » Fri May 09, 2003 9:34 pm

This command appears to be missing from PB's extensive command list, but in case anyone needs it, you can do it this way:

Code: Select all

Procedure.s CurrentDir() 
   ; This is the 'safe' version (Find out how big the buffer is first). A slightly less safe, but faster version would be: 
   ; sDir = Space(1000)   ; Safe as long as the actual path is not longer than the size of sDir 
   ; If GetCurrentDirectory_(1000,@sDir) 
   ;    ProcedureReturn sDir 
   ; Else 
   ;    ProcedureReturn "" 
   ; Endif 
   sDir.s = " "      ; Local variable 
   BuffSize.l = GetCurrentDirectory_(2,@sDir) ; Guaranteed to fail, but the return value is the required buffer length... 
   If BuffSize = 0                                    ; ...unless there was a REAL error (couldn't read dir, etc) 
      ProcedureReturn ""                            ; Couldn't get the directory path 
   EndIf 
   sDir = Space(BuffSize)                             ; So now we can re-call it with the correct size: 
   BuffSize = GetCurrentDirectory_(BuffSize,@sDir); And sDir contains the current full path (minus "\" at the end) 
   If BuffSize: ProcedureReturn sDir: Else: ProcedureReturn "": EndIf 
   ; We could have written this procedure with the string to be modified as the parameter (via a pointer), but the return 
   ; style is more like other other languages and probably easier to understand. 
EndProcedure

Works pretty good!
Here's a quick WaitMouse() and WaitKey() also (I missed these):

Code: Select all

Procedure WaitMouse() 
   ; InitMouse() must be called before calling this procedure 
   While MouseButton(1) = #FALSE And MouseButton(2) = #FALSE And MouseButton(3) = #FALSE 
      ExamineMouse() 
   Wend 
EndProcedure 

Procedure WaitKey() 
   ; InitKeyboard() must be called before this procedure 
   Repeat 
      ExamineKeyboard() 
   Until KeyboardPushed(#PB_Key_All) 
EndProcedure

WaitMouse() and WaitKey() halt program execution until a mouse click or a keypressed is detected (respectively). Unfortunately, they only work in OpenScreen() mode or OpenWindowedScreen() mode.

Hope this helps someone.

Russell
_________________
*** 6510: If it were 32 bits wide and ran at todays clockspeeds... would it beat a Pentium 4? ***

Henrik · Post by **Henrik** » Sat May 10, 2003 1:09 am

uhm your WaitKey() should work without openscreen.
actually i would have thought that a WaitMouse() fuction would worked too without openscreen but it seems it don't.

Code: Select all

If  InitKeyboard()=0
    MessageRequester("Argghhh","~ I Need DirectX 7  ",0)
    End
EndIf
If OpenWindow(0, 0, 0, 640, 480, #PB_Window_SystemMenu|#PB_Window_MinimizeGadget|#PB_Window_SizeGadget|#PB_Window_ScreenCentered, "~ Key test ~") 
endif

Repeat

  ExamineKeyboard()

Until KeyboardPushed(#PB_Key_All) 
end

Bedst regards
Henrik

PB · Post by PB » Sat May 10, 2003 1:55 am

For your WaitMouse() and WaitKey() procedures, you should stick a small
delay ( Delay(1) ) in the middle of the loop, otherwise your routines will use
100% of the CPU while waiting, which is not good.

Henrik · Post by **Henrik** » Sat May 10, 2003 2:48 am

@PB or anyone else..
would this be okay CPU-wise whitout using delay(1) ?
or should i still use dalay(1) in?

Code: Select all

Procedure WaitMouse() 

While Event <> #WM_LBUTTONDOWN And Event <> #WM_MBUTTONDOWN  And  Event <> #WM_RBUTTONDOWN

    Event = WaitWindowEvent()

Wend
End ;  * if mouse 1,2 or 3 end program

EndProcedure

Naa.. this is a foolish question i just got confused there 8O , it must be okay... it's late..

Bedst regards
Henrik.

PB · Post by PB » Sat May 10, 2003 2:58 am

Yes Henrik, that's fine because WaitWindowEvent() releases the CPU while
waiting, so you don't need a Delay(). I even tested it to make doubly sure,
and W2K reported 0% CPU while in the procedure.

Henrik · Post by **Henrik** » Sat May 10, 2003 3:10 am

PB wrote:Yes Henrik, that's fine because WaitWindowEvent() releases the CPU while
waiting, so you don't need a Delay(). I even tested it to make doubly sure,
and W2K reported 0% CPU while in the procedure.

Thank you PB, for your efford to help

I should have done that my self ofcouse

I did a test my self, -as i should have done- win98 using the CPU monitor from Resources site.
Before 16-23% and while the same.. so
i guess that sometime when your are tired one should just go to bed..

Bedst regards
Henrik.

PB · Post by PB » Sat May 10, 2003 6:21 am

No problem, Henrik.

Amiga5k · Post by **Amiga5k** » Sat May 10, 2003 8:40 pm

Thanks for the modifications, guys.

I was aiming to emulate the Blitz Basic command of the same name, and it does so, except that the BB version also returns the ascii code of the pressed key if you assign it to a variable:

Code: Select all

a = WaitKey()   ; Wait for key press, then return ascii code

Is there an easy way to do this in PB, short of writing a look up table of ascii codes?

By the way, the CurrentDir() routine is for finding out, for example, where your program is being run from, etc. But strangely, the WinAPI 'SetCurrentDirectory()' has no effect. I guess PB keeps track of this internally, and so API commands don't alter this internal reference?

And Henrik, you're right about WaitKey() working in windowed mode. I was equally surprised to find that WaitMouse() didn't work in windowed mode. I guess PB's mouse commands would somehow interfere with the OS's mouse messages?

Russell

Danilo · Post by **Danilo** » Sun May 11, 2003 8:35 am

@Amiga5k:
> By the way, the CurrentDir() routine is for finding out, for
> example, where your program is being run from

It doesnt work for this:
If the program is in 'c:\program files\cool\' and i start it from
console (command line): 'c:\> c:\program files\cool\cool.exe'
the current directory is 'c:\'.

To get the path of your program, use this:

Code: Select all

;
; by Danilo, 31.01.2003
;
Procedure.s ExePath() 
  ExePath$ = Space(1000) 
  GetModuleFileName_(0,@ExePath$,1000) 
  ProcedureReturn GetPathPart(ExePath$) 
EndProcedure 

MessageRequester("",ExePath(),0)

Amiga5k · Post by **Amiga5k** » Sun May 11, 2003 9:44 pm

Thanks for the clarification, Danilo. Thought I had it figured out!

Since 'C:\> C:\program files\cool\cool.exe' doesn't actually change the current directory, this is to be expected. For a typical app, I think most people are going to start it from the desktop so it would work as expected.

But a command line application, as you point out, would return an incorrect result if the console app is not in the starting directory.

Not sure why CurrentDir() is not part of PB's FileSystem command set

Thanks again!
Russell

Post by **freak** » Mon May 12, 2003 10:36 pm

If started from a Shortcut file, the results can also be wrong,
as you can change the current directory for an app there.

Better use the right solution, where no problems can occur.

Timo

TronDoc · Post by **TronDoc** » Tue May 13, 2003 10:52 am

Amiga5k wrote:But strangely, the WinAPI 'SetCurrentDirectory()' has no effect. I guess PB keeps track of this internally, and so API commands don't alter this internal reference?

It does work correctly, but not on all versions of WinDoze. --jb

PB · Post by PB » Wed May 21, 2003 1:52 am

> Is there an easy way to do this in PB, short of writing a look
> up table of ascii codes?

Here's an old tip I wrote:

viewtopic.php?t=3758

But it uses a look-up table, which you don't want...

PureBasic Forums - English

CurrentDir() with solution code

CurrentDir() with solution code

Re: CurrentDir() with solution code