How to create a multi-thread window

[skiman]

Chris -
I don't think you quite understand what Brian was asking for.

Yes, you are right. See also the post in this thread at the moment you posted your sample. I was expecting something different.

His Auction program has lots of windows, but there are 3 of them that are always opened at the same time. It occurred to him that it probably would have been better to merge the functionality of those 3 windows into a single window. However, due to the way his software was written, it would have been a large project. He wanted to know if he could take his existing code (in which each window is running in a different thread) and merge this code into a single window yet still have the original code running in it's own thread.

I thought that this was an interesting idea and that it was very possible to do. In fact, it is so easy to do that it could even become a configuration option which could be chosen by the user.

From your screen shot, it looks like you want to paint screen objects in the drawing area of the main window, but also want to maintain the functionality of separate windows.
Am I right about this?

Yes, again you are right. I'm afraid there is no easy solution for this.

If I look ato online ERP systems, they all have this kind of interface. Of course, they don't have multi-threading in their solution. However, in a browser you can easily open different tabs.

I'm thinking of implementing the new system, and remains the old system. It will be possible to configure what a user wants. I expect that old users will remain with the old functionality. For demonstration purposes and new users we will use the new system. It has a more 'modern' look.

[rdonnay]

This is my problem. I prefer the look when using the drawingarea, but I want the functionality of the old style. I don't know how to solve this.

I may have some ideas.
I will work on a sample program.

[skiman]

Roger,

You made me curious. Looking forward to your sample.

[bwolfsohn]

Chris,

Users are always opening and closing those windows. and opening others on top of them... Even with cascade, windows will get lost behind other windows. with the multi-threaded tab window, you can see by looking at the tabs which windows are open.

In addition, you can always open other dialogs in the software at the same time...

i haven't gotten full bore into this yet, but things that have occured to me are:

Can there be dynamic tabs... i.e. we have other file dialogs that are used less often, but would also do well as another tab.

How can exit button from one of the dialogs be used to go back up and exit the master multi-threaded tab dialog, instead of just closing that tab. Conversely, can it just close that tab and leave the others open ?

Lastly (for this moment), can these tabs be done w/ delayed mergegets to speed up the opening of the multi-threaded dialog. If they can be done with delayed mergegets, then each file dialog just have it's own tab (more than 3 tabs, more likely 6 or 7) and just be activated the first time the tab gets focus..

This has the possibility to be a major change in the ui if these things are possible...

[rdonnay]

Chris -

This may be what you are looking for:

Code: Select all

#INCLUDE "dcdialog.ch"

FUNCTION Main()

LOCAL GetList[0], oMenu, oSubMenu, oDlg, GetOptions

DC_LoadRdds()

DCMENUBAR oMenu
  DCSUBMENU oSubMenu PROMPT 'File' PARENT oMenu
    DCMENUITEM 'Single-Threaded Window' ;
      ACTION {|o|o := Thread():new(),Sleep(5),o:start({||DataBrowse(oDlg:drawingArea)})} ;
      PARENT oSubMenu

DCGETOPTIONS WINDOWWIDTH 1000 WINDOWHEIGHT 800
DCREAD GUI TITLE 'Window Test' PARENT @oDlg OPTIONS GetOptions ;
   EVAL {|o|o := Thread():new(),Sleep(5),o:start({||BackgroundWindow(oDlg:drawingArea)})}

RETURN nil

* ------------

PROC Appsys ; RETURN

* ------------

FUNCTION BackgroundWindow(oParent)

LOCAL GetList[0], GetOptions, i, j, oConfig, oDlg

oConfig := DC_XbpPushButtonXPConfig():new()

oConfig:mouseOverScale := 1.2
oConfig:mouseOverFont := '10.Arial Bold'
oConfig:fgColorMouse := GRA_CLR_BLACK
oConfig:bgColorMouse := GRA_CLR_WHITE
oConfig:radius := 10
oConfig:bgColor := GraMakeRGBColor({ 220,220,220 })

FOR i := 0 TO 20 STEP 5
  FOR j := 0 TO 70 STEP 12
   @ i,j DCPUSHBUTTONXP CAPTION 'Button ' + Alltrim(Str(i))+'/'+Alltrim(Str(j)) ;
      SIZE 10,4 ;
      ACTION {||MsgBox('I am button ' + Alltrim(Str(i))+'/'+Alltrim(Str(j)) ), ;
                oDlg:toBack()} ;
      CONFIG oConfig
  NEXT
NEXT

DCGETOPTIONS ;
   NOTITLEBAR ;
   BORDER XBPDLG_NO_BORDER ;
   COLOR GRA_CLR_BACKGROUND ;
   FITPAD 20

DCREAD GUI FIT APPWINDOW oParent OPTIONS GetOptions ;
   EVAL {|o|oDlg := o}


RETURN nil

* ------------

FUNCTION DataBrowse(oParent)

LOCAL oBrowse, GetList[0]

USE \exp20\data\xtest VIA 'FOXCDX'

@ 2,2 DCBROWSE oBrowse ALIAS 'XTEST' SIZE 96,20  FONT '10.Lucida Console'

DCBROWSECOL FIELD XTEST->areacode WIDTH 10 PARENT oBrowse
DCBROWSECOL FIELD XTEST->exchange WIDTH 10 PARENT oBrowse
DCBROWSECOL FIELD XTEST->number WIDTH 10 PARENT oBrowse
DCBROWSECOL FIELD XTEST->date WIDTH 10 PARENT oBrowse
DCBROWSECOL FIELD XTEST->time WIDTH 10 PARENT oBrowse

@ 23,2 DCSAY 'This Browse is running in Thread ' + Alltrim(Str(ThreadID())) ;
       SAYSIZE 0 FONT '12.Lucida Console'

DCREAD GUI FIT APPWINDOW oParent TITLE 'Data Browse Window'

dbCloseAll()

RETURN nil

[skiman]

Hi Roger,

I tested the sample, but was wondering the following.
The BackgroundWindow(oDlg:drawingArea) is running in another thread. But I don't understand the advantage of it. I can put these buttons on that dialog without any problem.

Code: Select all

...
DCMENUBAR oMenu
  DCSUBMENU oSubMenu PROMPT 'File' PARENT oMenu
    DCMENUITEM 'Single-Threaded Window' ;
      ACTION {|o|o := Thread():new(),Sleep(5),o:start({||DataBrowse(oDlg:drawingArea)})} ;
      PARENT oSubMenu

FOR i := 0 TO 20 STEP 5
  FOR j := 0 TO 70 STEP 12
   @ i,j DCPUSHBUTTONXP CAPTION 'Button ' + Alltrim(Str(i))+'/'+Alltrim(Str(j)) ;
      SIZE 10,4 ;
      ACTION {||MsgBox('I am button ' + Alltrim(Str(i))+'/'+Alltrim(Str(j)) )}  
  NEXT
NEXT	  
	  
DCGETOPTIONS WINDOWWIDTH 1000 WINDOWHEIGHT 800
DCREAD GUI TITLE 'Window Test' PARENT @oDlg OPTIONS GetOptions 

I don't see the difference or the advantage of this? I suppose I'm missing something?

[rdonnay]

Chris -

The background window did not need to be in another thread.
It would work either way.

This is different that what you are doing.
All the buttons are on a window that is on the drawing area rather than each button being on the drawing area.
I thought it would give you better control.

I guess I still don't understand what is your problem.

Roger

[skiman]

Hi Roger,

As you wrote:

From your screen shot, it looks like you want to paint screen objects in the drawing area of the main window, but also want to maintain the functionality of separate windows.
Am I right about this?

It looks as this will not work. Functionality has priority, but for demonstration purposes the look and the first impression are also very important.

[rdonnay]

This is so confusing to me.

I still do not know what kind of functionality you want.

Does everyone understand except me?

[bwolfsohn]

This is so confusing to me.

I still do not know what kind of functionality you want.

Does everyone understand except me?

Not really...

I think you & i are on the same wavelength... 1 window. multiple (previously independent) dialogs on that single window, each in it's own thread, and on it's own tab.

you still have the ability to open separate dialogs in their own windows and their own threads.

as far as owner drawing, i've never had the ability to draw, even when i was a kid.. it just looked like scribbling..