MODIFYSTYLE

[LarryMc]

Trying to use the command with my custom controls and it was giving me fits.
I'm using the lower 16 bits for configuring my custom buttons during the execution of controlex

I use the MODIFYSTYLE command to change the shape under program control.

The lowest 10 bits( 0x3ff ) I using to indicate my desired shape.

I kept getting odd results until I looked at the source code for the command.

The modifystyle command allows you to add and remove bits in one command.

It does that in one bitstring.

Problem is that if the new number you are trying to add  uses any bits that you remove the remove takes place after the add so your number changes.

You have to use the command twice.
Once to clear the bits used by the old number.
Once to set the bits for the new number.

Doing that makes it work great.

Took me an hour to figure out what was going on.  Should have looked at the source for the command sooner.

Just goes to show how good a deal your source code offer is.

Larry

[Ionic Wind Support Team]

Window styles use a single bit for each style.  So a simultaneous add and remove will work.

Paul.

[LarryMc]

It would work for what I'm doing if the add was after the remove instead of before the remove.
That change wouldn't have any impact on single bit styles.

Larry

[Ionic Wind Support Team]

For what you are using it for you would be far better off using window properties instead.  Search for GetProp and SetProp

Otherwise you could be conflicting with actual window styles.  Just about every bit has been used by Microsoft.

[LarryMc]

From what I read in the msdn docs about the style bits is that windows uses the top 16 bits for global type style bits and uses the lower 16 bits for specific types of windows/controls.  I looked up the value of each style bit mentioned in setwindowlong for GWL_STYLE and none of them were in the lower 16 bits.  I also looked at the options for the lower 16 in resedit and the lower 16 do different things for different controls.

Since my custom controls are not subclassing any other control I figured those bits were for me to use as I saw fit to control the style of my custom control.
If that's not the case then the only controls that can have style bits are those created by microsoft.
Is that true?

If I can't use those bits when I create my control (controlex) then I would have to create a empty square button then user would have to call another sub to set all the SetProps to get the right shape, shading direction, shading format, etc.  The very things I would think are perfect to set with style bits.

the scheme has been working for me so far.  I even have the resource dll working now.

Larry

Rev:  Found this in Dr.Dobb's

Style Flags
One of the parameters to CreateWindow() is a long word of style information. The high word is reserved for general window styles and the low word is used for individual control styles. If a control was written from scratch, all of the low-word style bits would be available.

[Ionic Wind Support Team]

Guess I just wasn't being clear.  GWL_STYLE is for style bits, and is not used for a discrete number, but you are using the lower 16 bits as a number and not a group of on/off bits. There is a potential for conflicting with window styles if you don't mask off the upper 16 bits.  I haven't seen your code yet, so I don't know what your "creation" function looks like, or if you are requiring the user to use ControlEx directly.

You can set a property when the control is created, and there is nothing wrong with having an additional parameter to specify 'shapes' which you store in the window property of the control.  I have a marquee control that I created long ago that does just that, no requiring a user to create something different just to store properties.

If you require the user to use ModifyStyle to change the shape, shading, whatever, then what would be the difference in having a subroutine to do it?  Some illumination from you might help me to understand better what you are doing.

Paul.

[LarryMc]

I am masking off the high order bits so as not to interfere with those system bits.
I am requiring the user to use ControlEx directly.
And I do have functions for users to use to change parameters.  It was in one of those functions that I was trying to use ModifyStyle.  Since it is inside a function then users won't know I'm calling it twice.

Plus, what I see as a normal user of my lib won't be changing shapes and shading style dynamically at runtime.

But I use that extensively in my custom button  control designer

I'm trying to make the coding as much like anything else they already do in EB.

BTW, instead of using SetProps to store all the config data for a given instance I am using a UDT pointed to by GWL_USERDATA.
Currently that UDT has 24 elements.

You do understand that I am in no way ignoring, and fully acknowledge, your emensely superior programming knowledge and skill relative to mine.
Therefore any program I write will never look like you wrote it.
Fortunately there is usually more than one way to accomplish a task.
I have to do things in a way I can understand them and am comfortable with.

I already feel I am pushing the limit in having you respond to windows api issues as opposed to EB issues.
I fully understand that support for EBasic does not include teaching someone like me windows.

It is perfectly acceptable for you to ignore my "issues" that are not directly focused on the EB language.
If I post a question and no one responds I'll eventually move on to something else; try a different scheme.

It's really all your fault for writing such a fantastic and powerful program language.
I would have never even dreamed of attempting to do some of the things I do routinely with EBasic.

I feel, based upon things I created with QBasic 30 years ago, that had I had EBasic back then I would have been extremely rich right now.

That's a tribute to your skill set.

Larry