The following code seems to have no effect on my slider (trackbar) control. If I set 'TBS-NOTICKS' in the CreateWindowEx, it works fine.

invoke GetWindowLong,[Slider],GWL_STYLE
invoke SetWindowLong,[Slider],GWL_STYLE,eax

I have also followed this code with a SetPosition call to no avail.

What is the proper way to change a control's style after it has been created?
Posted on 2003-07-01 15:04:11 by msmith
Do you have to redraw it to see the change?
Posted on 2003-07-01 15:51:16 by Will
The SetPosition is supposed to do this according to the MSDN lib docs.

I just tried an explicit UpdateWindow following the code, also to no avail.
Posted on 2003-07-01 16:48:34 by msmith
There is a message TBM_CLEARTICS that will remove the TICs from a TrackBar.

invoke SendMessage,,TBM_CLEARTICS,TRUE,0 ; TRUE is the redraw flag

I think that TBS_NOTICKS is one of those styles that cannot be changed. Like LBS_NODATA and such.
Posted on 2003-07-01 17:02:24 by donkey
You mean SetWindowPos(instead of SetPosition)? ... Try also checking for return value of the API functions and if there is an error use GetLastError.
Certain window data is cached, so changes you make using SetWindowLong will not take effect until you call the SetWindowPos function. Specifically, if you change any of the frame styles, you must call SetWindowPos with the SWP_FRAMECHANGED flag for the cache to be updated properly.
Posted on 2003-07-01 17:05:30 by arkane
Actually I just tried it and it works fine, add the following line :

invoke GetWindowLong,,GWL_STYLE
invoke SetWindowLong,,GWL_STYLE,eax
invoke InvalidateRect,,NULL,TRUE
Posted on 2003-07-01 17:09:31 by donkey
Hi Donkey!

I tried your fix and still no good.

Maybe it's becuase I'm putting this code in the wmcreate event handler.

Here's my latest (with your fix) that stil has ticks on the slider:

invoke CreateWindowEx,0,!slider,NULL,WS_VISIBLE+WS_CHILD,0,0,0,0,[OBMain],108,[!hinstance],NULL
mov dword [Slider],eax
mov dword [Slider+4],108
invoke GetWindowLong,[Slider],GWL_STYLE
invoke SetWindowLong,[Slider],GWL_STYLE,eax
invoke InvalidateRect,[Slider],NULL,TRUE
mov eax,300
mov [_ArgSafe0],eax
mov eax,40
mov [_ArgSafe1],eax
mov eax,80
mov [_ArgSafe2],eax
mov eax,15
mov [_ArgSafe3],eax
invoke SetWindowPos,[Slider],HWND_BOTTOM,[_ArgSafe0],[_ArgSafe1],[_ArgSafe2],[_ArgSafe3],0

The purpose of this whole exercise really has little to do with sliders or ticks, but rather the style I want to use to construct controls with my compiler. Since most of the controls will be "drawn" with an IDE, I would prefer to set all styles with SetWindowLong after the control exits. Then the controls would always be constructed as vanilla as possible.

But in order for this idea to work, I need the same capability to set styles 'later' as if they were incorporated in the CreateWindowEx.

Posted on 2003-07-01 18:17:30 by msmith
I used a dialog to test with so there may be a problem with the control not yet being able to accept messages, I have seen that with scroll bars as well. These were my results with a dialog :
mov eax,uMsg

mov eax,hWin
mov hDlg,eax
invoke GetDlgItem,hDlg,1002
mov hTB,eax
invoke SendMessage,hTB,TBM_SETTICFREQ,2,0

invoke GetWindowLong,hTB,GWL_STYLE
invoke SetWindowLong,hTB,GWL_STYLE,eax
invoke InvalidateRect,hTB,NULL,TRUE
Posted on 2003-07-01 18:28:28 by donkey
Hi msmith,

Why not just save the full numeric style of the control and use that in CreateWindowEx. Your method will lead to problems, there are many controls that do not return the proper values from GetWindowLong. For example an edit control will never return WS_BORDER even if it is set. To top that off, GetWindowLong does not necessarily use the value of the style when returning from GWL_STYLE, it may elect to use internal Windows flags and return a value that has little or no relation to the actual style of the control. I purposely avoid using GWL because it cannot be relied upon.

Here is the KB article :
Posted on 2003-07-01 18:39:07 by donkey
Hi Donkey

As usual, here you are with the answer(s).

Also, as usual, I find yet another non-orthagonal aspect of the Windows API.

I have been struggling for the past several months on whether to use a GUI package like wxWindows or GTK+ or to use the straight Win32 API. I decided to go with the API because the whole package would be "lean and mean".

I will probably stay with my decision to use the API, but the info you point to on the Microsoft site is very disappointing.

With the GUI package (FOX) I used on the earlier version of my compiler, setting styles was no problem. The Windows API appears to be half-baked.

As usual, Thanks Donkey
Posted on 2003-07-01 19:39:52 by msmith

Also, as usual, I find yet another non-orthagonal aspect of the Windows API.

Well, not quite orthagonal, more wavy and erratic, bordering on schitzophrenic would be my estimation. I'm currently dealing with updating resources and it's humorous to see that there are functions that are not implemented in 9x but still compile only to return 0 (success) all the time but do nothing. Try debugging that something when you can't trust the results that are returned (like GWL) ! I've managed to get them working with MSLU, but even that had to be implemented exactly the opposite of what MSDN detailed. Using MS directions I had over 100 assembly errors, doing the exact opposite I had none and everything worked :rolleyes:
Posted on 2003-07-01 20:32:45 by donkey
There are other problems with the docs.

Yesterday when I was testing new controls for my compiler, I couldn't find the class name for slider (trackbar).

A search on MSDN did not return even one instance of the class name for this control.

A search of the web turned up the following list.

Is this list complete?

The list:


Also the SysMonthCal32 control did nothing on my Win98 system. It worked fine on WinXP (home version)
Posted on 2003-07-01 20:48:06 by msmith
That seems to be about it, for SysMonthCal32 you have to have Common Cotnrols version 4.72 or better, that came with IE 5 I think. Check the CC version number like this :
CheckLibVersion proc

LOCAL pComCtrllib :DWORD
LOCAL pGetVersion :DWORD

jmp @F
LibName BYTE "comctl32.dll",0
FuncName BYTE "DllGetVersion",0

invoke LoadLibrary,ADDR LibName
mov pComCtrllib,eax
.IF eax != NULL
invoke GetProcAddress,pComCtrllib,ADDR FuncName
mov pGetVersion,eax
.IF eax != NULL
lea eax,LibVersion
push eax
call pGetVersion
invoke FreeLibrary,pComCtrllib

.IF (LibVersion.dwMajorVersion == 5 && LibVersion.dwMinorVersion >= 80) || LibVersion.dwMajorVersion > 5
mov eax,TRUE
mov eax,FALSE
CheckLibVersion endp
This one checks for 5.80 (for ballons tips I think, I wrote it a while ago)
Posted on 2003-07-01 20:57:19 by donkey
Hi Donkey

Notwithstanding your caveat regarding GWL, my test now works.

I ran across the solution by luck.

I was also having a problem that some controls (static, radiobutton, checkbutton, and the text on groupbox) all had white rectangular backgrounds.

I worked for hours to discover that the problem was in my PE declaration.

I had "format PE GUI".

Changing it to "format PE GUI 4.0" fixed the problem.

When I tested the program for the white backgrounds, I noticed that the tick marks were also gone from my slider.

Further checking revealed that no refresh code was required in order to repaint the control.

What is the significance and meaning of the "4.0" in the declaration. I am using fasm.

Also, I updated comctl32.dll and still have no calendar control on win98, but still do on XP(home).

Posted on 2003-07-05 00:38:59 by msmith
The 4.0 probably means a Win32 PE.

Use the following (MASM) to initialize your controls.

icc DWORD 00000008,00003FFFh
invoke InitCommonControlsEx,OFFSET icc
Posted on 2003-07-05 01:30:27 by donkey
Hi Donkey!

The InitCommonControlsEx did the trick for the calendar. I originally had that code in there, but took it out because all the controls from comctrl32.dll (up to that time) seemed to work without it. Again, so much for orthagonal!


Posted on 2003-07-05 11:06:54 by msmith
No problem msmith,

It depends on wether there is another application that has loaded the common control dll and classes. You have to load them to make sure that they are available, it says that somewhere in the docs.

I took a look at the command set for your omnibasic and it looks pretty good. I would suggest a bswap function, I do alot of file decoding and that one is essential.



Bytes are reversed in order and output in Motorola format:




Just have to convert it directly to opcode (486+ = BSWAP eax)
Posted on 2003-07-05 12:01:40 by donkey
Hi Donkey!

Thanks for the kind words on OmniBasic. The new version is much nicer than the version I assume you looked at (the stuff on the web).

On the old or new version, I can accomplish the BSWAP function by using based variables (vectors):

dim x as long
dim v1(4) as byte vector

setvec v=addr(x)
exchange v1(1),v1(4)
exchange v1(2),v1(3)
' x will now contain $AABBCCDD

If you think BSWAP would be used often I could make a BSWAP as part of the language.

You can see that vectors are in some sense similar to pointers, but are easier to use. Omni also has pointers. I prefer vectors.

Posted on 2003-07-05 13:28:02 by msmith
Well, BSWAP depends on what type of programming you do. If you're working with files alot and decompiling different types of files it is used constantly. For example if you are decoding a lib file you must reverse the byte order on every offset in the file. The same applies to MP3 files in converting DWORDs to SyncSafe DWORDs. For me, I like taking apart files so I use it alot.

I do like the look of the language but I have to admit that I am perplexed by high level languages and have never managed to successfully learn one so I am pobably the last person to make suggestions. Anyway once you are in the grasp of ASM it's hard to wrestle free, not that you would want to :) .
Posted on 2003-07-05 13:41:04 by donkey
Then it's a done deal. I will add it to the built-in functions. I might even be able to optimize it for speed that way.



BTW This new version compiles to asm and allows you to stop the process and look at the .asm file. Otherwise, it will compile to asm and call fasm for you. Also, inline asm is allowed.

When you look at the asm file, all libs are there in source form and each line of OmniBasic is an asm comment followed by the generated code.
Posted on 2003-07-05 15:26:54 by msmith