CSED - Modification

[Gary Beene]

Well, there's an interaction of some kind going on ... something I've apparently not understood ...

This code correctly ends on it's own, after identifying the 3 available values of hMDI:

Code Select Expand

   hMDI = GetWindow(pSed.hwndClient, %GW_Child)
   While hMDI
      hMDI = GetWindow(hMDI, %GW_HWNDNEXT)                  'get next TAB
   Wend

One or more of the other lines in this failing example is messing with the hMDI loop value, perhaps?

Code Select Expand

   hMDI = GetWindow(pSed.hwndClient, %GW_Child)
   While hMDI
      vPath = AfxGetWindowText(hMdi)                        'get path from the collection
      nTab = CSED_GetTabNumberFromPath(Variant$$(vPath))    'get TAB number from Path
      TabCtrl_SetCurSel(pSed.hTabMdi, nTab)                 'select the TAB
      MDIActivate(pSed.hwndClient, hMdi)                    'activate this MDI child window
      hMDI = GetWindow(hMDI, %GW_HWNDNEXT)
   Wend
The chase is afoot!

[Gary Beene]

Just by eliminating lines, this lnext line seems to be the culprit!  When removed, the loop ends as expected.

Code Select Expand

MDIActivate(pSed.hwndClient, hMdi)                    'activate this MDI child window

I thought, by activating the TAB corresponding to hMDI, that the corresponding Scintilla Control would become active and be reported by pSed.hEdit (I need the Scintilla control handle in order to search its text content)

But it seems that the activation also messes with hMDI?  I'll go look at Jose's code for the MDIActivate function.

(sorry if it seems like I'm talking to myself here.  Just thinking through the process ...)

[Gary Beene]

So, if MDIActivate cannot be used in the loop, I guess I need another approach to making the scintilla control active (corresponding to nTAB or vPath in the loop) so I can access it using pSed.hEdit.

[José Roca]

You don't need to activate the MDI window or use pSed.hEdit to access the scintilla control. As you have the handle of the MDI window (hMdi) you can just use hSciCtrl = GetDlgItem(hMdi, %IDC_EDIT) to get the handle of the control, do the search and, if found, then activate the MDI window, select the associated tab and leave the loop.

[José Roca]

Someting like this:

Code Select Expand


LOCAL hSciCtrl AS DWORD
hMDI = GetWindow(pSed.hwndClient, %GW_Child)
While hMDI
   hSciCtrl = GetDlgItem(hMdi, %IDC_EDIT)
   IF hSciCtrl THEN
      ' Do the search
      ' ---
      ' IF found...
      vPath = AfxGetWindowText(hMdi)
      nTab = CSED_GetTabNumberFromPath(Variant$$(vPath))
      TabCtrl_SetCurSel(pSed.hTabMdi, nTab)
      MDIActivate(pSed.hwndClient, hMdi)
      EXIT DO
   END IF
   hMDI = GetWindow(hMDI, %GW_HWNDNEXT)
Wend


BTW instead of vPath you can use an STRING if ansi is enabled or a WSTRING if unicode is enabled.

Code Select Expand


#IF %DEF(%UNICODE)
   LOCAL strPath AS WSTRING
#ELSE
   LOCAL strPath AS STRING
#ENDIF
LOCAL hSciCtrl AS DWORD
hMDI = GetWindow(pSed.hwndClient, %GW_Child)
While hMDI
   hSciCtrl = GetDlgItem(hMdi, %IDC_EDIT)
   IF hSciCtrl THEN
      ' Do the search
      ' ---
      ' IF found...
      strPath = AfxGetWindowText(hMdi)
      nTab = CSED_GetTabNumberFromPath(strPath)
      TabCtrl_SetCurSel(pSed.hTabMdi, nTab)
      MDIActivate(pSed.hwndClient, hMdi)
      EXIT DO
   END IF
   hMDI = GetWindow(hMDI, %GW_HWNDNEXT)
Wend


[Gary Beene]

Jose,
I want to include the Project Name (in the mod I'm working), along with the currently selected file nam,  in the main window caption.  Can you point me to the section of code that changes the caption?

I've found all instances of SetWindowText, but as best I can tell, none affect the main window.

I also searched for all instances of $PROGNAME, $CDSEVERSION and $CSEDCAPTION. But likewise, none of these helped me locate the caption changing code.

I also tried tracing File New and tracing a click on the a tab, but still I don't see where the caption is changed!

Surely it's right under my nose, but I'll be darned if I can see it!

[José Roca]

In the line 168 of CSED.BAS, the content of the constant $CSEDCAPTION is used as the title of the main window.

Code Select Expand


   hwndMain = pWindow.CreateWindow(%NULL, $CSEDCAPTION, _
              0, 0, rc.Right - rc.Left, rc.Bottom - rc.Top, -1, -1, CODEPTR(CSED_WindowProc), %TRUE)


[Gary Beene]

Hi Jose,
Yes, thank you, I found that.

But when a new file is opened, the caption is changed from $CSEDCAPTION to include the new file name.  That's what I don't find - where the caption is modified during execution of the program.

[Gary Beene]

Perhaps this is one of those MDI features, where you only specify the file path and the MDI code adds that to the window caption?

I was expecting something like ... $CDSECAPTION + strPath ... where the code specifies the entire caption.

Instead perhaps an MDI statement only requires the strPath and it adds that to the caption without your code explicitly having to use the term $CSEDCAPTION in the code? 

I'll go see if that thought helps me ....

[José Roca]

Please, reread the reply #18. You must try the editor with the "Maximize edit windows" unchecked.

Each MDI window has its own caption, independent of the main window's caption. When you maximize the MDI window, Windows merges its caption with the one of the main window, making it to appear as if there is only one caption, but there are two. I never change the main window's title, only the one of the MDI windows. And I only use the path as a way to easily retrieve it without having to use, for example, a global array of paths (I always try to avoid to use globals, you know).

[Gary Beene]

Jose!
When I finish the CSED mods I'm working on, what's the protocol for releasing the modified version of CSED, and the source code to go with it?   

I see your copyright statements in the source code files, so I want to make sure I follow your requirements for releasing any modifications I come up with.

[José Roca]

Just made it available, here or elsewhere, it does not matter. As stated in the CSED thread:

Permission is granted to develop new versions of the editor as long as the source code is made freely available in this forum or elsewhere.

[Gary Beene]

Jose,
Just a general question about coding, regarding your code in CSED ...

In the window procedure you seem to always put EXIT FUNCTION after each Case option.  Is there ever a case where not putting in EXIT FUNCTION won't exit correctly?

In my apps, all code in DlgProc is found within Case options.  There's no code that will execute if EXIT FUNCTION is not explicitly used.  But since you use EXIT FUNCTION in every Case, I thought perhaps that means you are explicitly avoiding something? The question is what?

[José Roca]

SDK callbacks don't work exactly as DDT callbacks. Exiting the function when the message has been processed avoids the call to DefWindowProc (if it is a message for the main window) or DefFrameProc (if it is a message for the MDI client window).

MDI applications are more complicated that the non-MDI ones. Besides DefWindowProc and DefFrameProc, there is also DefMDIChildProc, which processes messages for MDI child windows.

In a non MDI SDK application, I use FUNCTION = DefWindowProc(hwnd, uMsg, wParam, lParam) as the last line of the function, after the SELECT CASE block. Therefore, if EXIT FUNCTION isn't used, the call to DefWindowProc is executed. DefWindowProc calls the default window procedure to provide default processing for any window messages that an application does not process. This function ensures that every message is processed. So EXIT FUNCTION must be used when you have processed the message and you don't want that the system will execute any default action.

For example, to avoid flicker, a SDK application often proccesses the WM_ERASEBKGND message and exits the function with a return value of 1. This prevents that Windows will erase the background and leaves the repainting to you.

EXIT FUNCTION is not used in all the procesed messages. Sometimes, you process the message to do something special and you also lets DefWindowProc to perform the default action.

With SDK you have full control. This means more power, but requires more knowledge.

There are also differences on how keyboard messages are processed depending if the message pump uses IsDialogMessage or not. In general, IsDialogMessage is used when the application has child controls such buttons, etc., and not used in graphic applications. You can find a good article about message pumps in the PB Gazette #38: http://www.powerbasic.com/support/downloads/gazette/gaz038.txt

Because of these and other differences, I avoid to mix the use of SDK for some applications and DDT for others, because it is easy to make mistakes. I wrote the CWindow class to simplify GUI programming, as DDT does, but still is SDK, meaning that there are no differences in the processing of the messages.

[Gary Beene]

Thanks, Jose, for the information.  Even if I'm not writing in SDK, I'm still interested in learning more about it and will likely write some apps with it just for the experience, if nothing else.  But what I really am interested in, with SDK, are app demonstrations which cannot be done without SDK.  I know I've mentioned the idea in another thread, and will pursue it more next week.

Regarding CSED ...

I've got my mod (projects support and search for procedures, including searching unloaded source code files in project file folder) to CSED up and running. I'm just doing testing on it right now.  I hope to have it out in within the week.  I appreciate the help you've given in getting me past a few sticking points with SDK and MDI.