Scroll Bars..

Started by Tyrone Lee, June 16, 2006, 09:54:53 PM

Previous topic - Next topic

Tyrone Lee

I am having trouble setting SCROLLBAR properties.. I'm simply looking for the Min/Max & Value..

Tye

TechSupport

Try using the following:

Local tScrollInfo As SCROLLINFO  

tScrollInfo.cbSize = SizeOf( SCROLLINFO )
    tScrollInfo.fMask  = %SIF_ALL
tScrollInfo.nMin   = 100
tScrollInfo.nMax   = 1000
tScrollInfo.nPos   = 200

SetScrollInfo HWND_FORM1_HSCROLL1, %SB_CTL, tScrollInfo, %TRUE


GetScrollInfo HWND_FORM1_HSCROLL1, %SB_CTL, tScrollInfo

MsgBox "Min:" & Str$(tScrollInfo.nMin) & $CrLf & _
      "Max:" & Str$(tScrollInfo.nMax) & $CrLf & _
      "Position:" & Str$(tScrollInfo.nPos)


You should download the Win32.hlp file because there are hundreds of api functions in there that work with every Windows control. Of course, functions for scrollbars should really be built into the "FireFly Functions".

Tyrone Lee

Thanks... I found out how to do it with the CONTROL SEND command. But I will check out the Win32.hlp file.

The more I use FF, the more I like it.. But I come to realize that the IDE forces the user to create "non-standard" code. Meaning, all of the FF_COMBOBOX_{FUNCTION} code is really quite ugly.

In VB, When you create ActiveX controls you use a SetProperty(), GetProperty() style function.

I've setup some equates for ControlType and PropertType and constucted a simple function that works like this..

SetProperty ("MYTEXT", "WIDTH", "30")
GetProperty$("MYTEXT", "WIDTH")
or
SetProperty (ctrlHandle, "WIDTH", "30")
GetProperty$(ctrlHandle, "WIDTH")

This may allow for the controls types & properties to be sorted by the compiler. And would allow FF to have a more "standard" looking code syntax. Tell me what you think..

Tye

TechSupport

I guess it all depends on what you think is "non-standard" :)  If you use VB as the benchmark then you will find many instances where PB/WinAPI code will differ. I like your GetProperty/SetProperty idea. Have you actually implemented the code for it? I can imagine the code being quite substantial when you take into consdieration the 20 or so standard and common controls and all of their individual properties that require setting and retrieving by different api functions.

Actually, your approach would certainly make it easier for FireFly to generate its code output. I could simply create a standard GetProperty/SetProperty function and call it when setting each property during code output. I will certainly keep this in mind when writing the FireFly 3 code generator. Thanks.

Tyrone Lee

Yes... I've started doing this in PB.. I did it years ago for VB. The point was to allow my Script Engine/Parser be able to manipulate VB forms & Controls.

I imagine that it would make your FF Code Generation much easier which is why I suggested it. :) I wanted to "get your vision" or your direction so I could make a VB  to FF Importer..  Sorta like you working from one end, and me working from another and meeting in the middle.

You current approach of functions is OK, but I thought the Get/Set idea would make a good standard. My Vision is this..

Make an importer to scan the VB project, determine Forms & Control Names.

MainFrm.List1.ListIndex = 1

would be converted to..

SetProperty("MAINFRM_LIST1", "LISTINDEX", "1")

You can see it would convert easily..

Complex settings would require some work but you get the point.. Using your current method of functions could work, but I would need more info of the Propertynames you want to use..

You use CURSEL for ListIndex.. So I could convert using this syntax.

FF_{CONTROLCLASS}_{PROPERTY}

If I knew all of the "future" property names you would use. If you aren't going to follow VB it would be a little hard. (ie you haven't made public your Scrollbar property functions yet, MIX/MAX/VALUE)


I also noticed that there is some work/improvement needed on Parent/Child support for frames and option buttons.. You could establish some pointer holders for the ParentChild. And make your default Functions for OptionButtons accept a pointer to a list of options in the group, rather than the first & last.

I'm a wiz and string & data processing so I throw around data CSV arrays, pointers and whatever to get the job done.  Something like this..

FF_Control_SetOption HND_FORM1, #of Options, ptrIDC_Options, IDC_OPTIONTOSET


It could add more functionality.. And if a "standard" could be established, there may be a way to directly communicate with custom ActiveX controls exactly like VB. I think by making some of these "core" things easier/clearer you could open up your other areas to explore.


Tye