PeekS() & Unicode same very old problem!

[Thunder93]

Can someone tell me if this isn't a problem, and a very old one with PeekS() reading & conversion from memory of the stored Unicode to ASCII ? With bare minimum repeats and with the changed lengths, I'm having still, the problems.



sd\7.doc REMOVED
File Length from Stored Structure: 16
PB MemoryStringLength(): 8
Filename$ Length: 8
-
sd\8.txt REMOVED
File Length from Stored Structure: 16
PB MemoryStringLength(): 8
Filename$ Length: 8
-
sd\22.txtB REMOVED <------- B char shouldn't be there
File Length from Stored Structure: 18
PB MemoryStringLength(): 10 <--------- from Unicode reading '18 / 2 != 10' its 9 right?!?!
Filename$ Length: 10
-
sd\1111.txt REMOVED
File Length from Stored Structure: 22
PB MemoryStringLength(): 11
Filename$ Length: 11
-
sd\6666666.rtf4 REMOVED <---------------------------------
File Length from Stored Structure: 28
PB MemoryStringLength(): 15
Filename$ Length: 15
-
sd\333333333333.png_4 REMOVED <---------------------------------
File Length from Stored Structure: 38
PB MemoryStringLength(): 21
Filename$ Length: 21
-

[Thunder93]

The only way is to not be reading the file length stored in the pointer structure from within PeekS(). Instead we are needing to store the length in a LONG variable first and have PeekS() length field use that instead of using memory reference.

[Nico]

Where is your code to test?

[Thunder93]

Apologies, there are various and interesting codes on the PB forum that shares this issue, I'm using Monitor FileSystem Changes ReadDirectoryChangesW - by jpfiste http://www.purebasic.fr/english/viewtop ... 12&t=47060

Code: Select all

; Notify filter values
#FILE_NOTIFY_CHANGE_FILE_NAME = 1
#FILE_NOTIFY_CHANGE_DIR_NAME = 2
#FILE_NOTIFY_CHANGE_ATTRIBUTES = 4
#FILE_NOTIFY_CHANGE_SIZE = 8
#FILE_NOTIFY_CHANGE_LAST_WRITE = $10
#FILE_NOTIFY_CHANGE_LAST_ACCESS = $20
#FILE_NOTIFY_CHANGE_CREATION = $40
#FILE_NOTIFY_CHANGE_SECURITY = $100
#FILE_NOTIFY_CHANGE_ALL = $17F

; not defined in purebasic
#FILE_SHARE_DELETE = 4

; Notify events
Enumeration
  #FILE_ACTION_ADDED = 1
  #FILE_ACTION_REMOVED
  #FILE_ACTION_MODIFIED
  #FILE_ACTION_RENAMED_OLD_NAME
  #FILE_ACTION_RENAMED_NEW_NAME
EndEnumeration

; Needed for creating a watching thread
Structure WatchFSParam_t
  Directory.s
  Filter.l
EndStructure

; structure for the needed
Structure FILE_NOTIFY_INFORMATION
  NextEntryOffset.l
  Action.l
  FileNameLength.l
  Filename.s{512}
EndStructure

Import "kernel32.lib"
  ReadDirectoryChangesW(hDirectory.l, *lpBuffer, nbBufferLen.l, bWatchSubTree.b, dwNotifyFilter.l, *lpBytesReturned.l, *lpOverlapped.OVERLAPPED, lpCompletitionRoutine)
EndImport

Procedure WatchDirOrFile(*params.WatchFSParam_t)
  
  Protected *buffer = AllocateMemory(32*1024)
  Protected *ovlp.OVERLAPPED = AllocateMemory(SizeOf(OVERLAPPED))
  Protected dwOffset.l = 0
  Protected *pInfo.FILE_NOTIFY_INFORMATION
  
  hDir = CreateFile_(*params\Directory, #FILE_LIST_DIRECTORY, #FILE_SHARE_READ | #FILE_SHARE_WRITE | #FILE_SHARE_DELETE, #Null, #OPEN_EXISTING, #FILE_FLAG_BACKUP_SEMANTICS, #Null)
  
  While ReadDirectoryChangesW(hDir, *buffer, MemorySize(*buffer), #True, *params\Filter, bytesRead, *ovlp, #Null)
    
    dwOffset = 0
    
    Repeat
      
      *pInfo = *buffer + dwOffset
      
      filename$ = PeekS(@*pInfo\Filename, *pInfo\FileNameLength, #PB_Unicode)
      
      action$ = #NULL$

      Select *pInfo\Action
        Case #FILE_ACTION_ADDED
          action$ = "ADDED"
        Case #FILE_ACTION_MODIFIED
          action$ = "MODIFIED"
        Case #FILE_ACTION_REMOVED
          action$ = "REMOVED"
        Case #FILE_ACTION_RENAMED_NEW_NAME
          action$ = "RENAMED_NEWNAME"
        Case #FILE_ACTION_RENAMED_OLD_NAME
          action$ = "RENAMED_OLDNAME"
      EndSelect
      
      AddGadgetItem (0, -1, filename$ + " " + action$)
      
      dwOffset + *pInfo\NextEntryOffset
      
    Until *pInfo\NextEntryOffset = 0
    
  Wend
  
EndProcedure

Procedure.l WatchFileSystem(DirectoryName.s, NotifyFilter.l = #FILE_NOTIFY_CHANGE_FILE_NAME)
  
  *watcherparams.WatchFSParam_t = AllocateMemory(SizeOf(WatchFSParam_t))
  *watcherparams\Directory = DirectoryName
  *watcherparams\Filter = NotifyFilter
 
  CreateThread(@WatchDirOrFile(), *watcherparams)
  
EndProcedure



; USAGE
If OpenWindow(0, 0, 0, 320, 240, "FileSystemWatch", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  
  ListViewGadget(0, 10, 10, 300, 200)

  WatchFileSystem("C:\Test")

  Repeat
    Event = WaitWindowEvent()
    Delay(5)
  Until Event = #PB_Event_CloseWindow
  
EndIf

[cas]

Problem is with this line:

Code: Select all

filename$ = PeekS(@*pInfo\Filename, *pInfo\FileNameLength, #PB_Unicode)

You need to change it to:

Code: Select all

filename$ = PeekS(@*pInfo\Filename, *pInfo\FileNameLength / 2, #PB_Unicode)

Reason: 2nd parameter to PeekS() is number of characters to read and \FileNameLength is size in bytes of \Filename. So you need to divide \FileNameLength by 2 to get number of characters that are stored in \Filename and pass that number to PeekS().

[Thunder93]

I knew what line was the culprit, and I knew I was reading Unicode size. I even already had it fixed with;

Code: Select all

Length.i = *pInfo\FileNameLength
filename$ = PeekS(@*pInfo\Filename, Length/2, #PB_Unicode)

I don't know why I didn't just do the division all in that PeekS parameter, don't know what was going through my mind at the time. And looking at the high number of posted codes by smart folks that dates to way back several years ago. They all seem to think that the division supposed to be automatically handled by PeekS(), even works until you place it in a repeated loop. Then she works here and there.

I'm going to assume the majority has it right, and that there is a PB bug here.

[cas]

There is no bug. You just need to read documentation carefully, i had same problem in past when i assumed things without reading manual. I learned my lession.

[Thunder93]

I was going by the majority's examples (and they were smart PB folks), I thought if the PB smart people are doing it, then I'm misunderstanding the help file. I guess this just goes without saying, even smart ones makes mistakes.

[rsts]

What "majority" are you referring to?
Can't be the silent majority.

[Thunder93]

LOL! That's true... !

What "majority" are you referring to?
Can't be the silent majority.