Page 5 of 6

Re: Screenshots requested

Posted: Sun Mar 29, 2015 6:14 pm
by pedroah
Hi Skiman

Yes it is....

Re: Screenshots requested

Posted: Sun Mar 29, 2015 7:35 pm
by rdonnay
Pedro -

I like what you have done with the ribbon bar. It's very simple and not cluttered but elegant looking.

Do you have a small code sample?

Roger

Re: Screenshots requested

Posted: Sun Mar 29, 2015 11:10 pm
by Wolfgang Ciriack
I removed the Codejock ribbonbar from my app, because it slow down the app and sometimes did not react anymore.

Re: Screenshots requested

Posted: Mon Mar 30, 2015 9:46 am
by Cliff Wiernik
What are the values of these defines:

COLOR_BLACK
BD_KEYLIME

Re: Screenshots requested

Posted: Mon Mar 30, 2015 10:29 am
by rdonnay
Look in \exp19\Samples\COLORVIEW\bdcolors.ch

Re: Screenshots requested

Posted: Mon Mar 30, 2015 1:38 pm
by Auge_Ohr
Wolfgang Ciriack wrote:I removed the Codejock ribbonbar from my app, because it slow down the app and sometimes did not react anymore.
i did not think "Codejock" is the Problem ... it is how Alaska handle activeX which is (very) slow ... and often "block" GUI Thread.

it does happend with XbpStatusbar() or XbpToolbar() when simulate "quick click" e.g. send 1000 PostAppEvent() to those Controls which based on M$ComCtl.OCX

you can use ot4xb and DispHPR instead of Alaska activeX when not need Notify Events.

Re: Screenshots requested

Posted: Tue Apr 07, 2015 1:10 pm
by bwolfsohn
Roger,

This is a screenshot of one of our dialogs
lotonly.jpg
lotonly.jpg (174.27 KiB) Viewed 51914 times
Each of 3 main dialogs (buyer, lot, seller) opens up from the main menu in it's own window/thread. not modal.

My staff has just asked me about the possibility of placing all these dialogs into another window inside our application thusly:
BLStabs.jpg
BLStabs.jpg (239.28 KiB) Viewed 51914 times
I'm thinking each tab would probably still need to have it's own thread, (to avoid re-writing all the logic coming from each dialogs actions) but from a U.I. POV, it would be very good for our users.

might this be possible ??

Re: Screenshots requested

Posted: Tue Apr 07, 2015 1:32 pm
by rdonnay
I'm thinking each tab would probably still need to have it's own thread,
(to avoid re-writing all the logic coming from each dialogs actions) but from a U.I. POV,
it would be very good for our users.

might this be possible ??
That's an interesting idea and I think it is possible.

I will work on a sample program.

Re: Screenshots requested

Posted: Tue Apr 07, 2015 11:58 pm
by skiman
Hi,

I thought about this some weeks ago. Using TAB pages is a nice look and feel. A problem I see is that a user can now open easily the same function/thread several times. Then he can move the dialog to the place he wants. When using tab-pages, it won't be possible to do this?

This is the look I made. I'm wondering how a user could open Customers (klanten) two times. Now it opens two dialogs in a different thread.
mainscreen.jpg
mainscreen.jpg (91.59 KiB) Viewed 51902 times
The 'tabpages' are in fact buttons on a toolbar. The height of the toolbar is 38, at row 12 I put buttons with a height of 30. This way they look as a tab.

Re: Screenshots requested

Posted: Wed Apr 08, 2015 3:35 am
by Auge_Ohr
when start with Codejock Control we realize that Windows "real" Tabpage ist different to Alaska XbpTabpage()
Windows API does have a TabControl ( WC_TABCONTROL ) but there is no "Body" ...

we did add a XbpStatic as Parent for Xbase++ and use SetParent() API to attach it to TabControl.
TabControl just switch Tabs and Hide()/Show() "Body" so in general it is possible to use a XbpDialog instead of XbpStatic as "Body"