Re: CommonControls (Replacement of the MS common controls)
Hi Krool, thanks for the feedback.
As for #2, I'll review my approach there.
Regarding #3, I'm using a virtual machine with XP as the OS, so that might explain why it doesn't work. There is still too much cleaning up to do after transitioning all existing conbtrols to the VBCCR ones, to do a full compile and test the behavior on Win10. However, these textboxes are for display only, so I can do a workaround with a label with a transparent background in front of the colored textbox, which will solve my problem. So, either way you decide to address it, will work for me. I just wanted you to be aware of it.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Erwin69
Regarding #3, I'm using a virtual machine with XP as the OS, so that might explain why it doesn't work. There is still too much cleaning up to do after transitioning all existing conbtrols to the VBCCR ones, to do a full compile and test the behavior on Win10. However, these textboxes are for display only, so I can do a workaround with a label with a transparent background in front of the colored textbox, which will solve my problem. So, either way you decide to address it, will work for me. I just wanted you to be aware of it.
It's really a pain in the ...
This here again good example.
I am considering a small overhead (e.g. like done in the ComCtlsW2KCompatibility function)
The overhead is only once per process lifetime. It would be then a ComCtlsWXPCompatibility function.
If either W2K or WXP is true it makes ES_CENTER/ES_RIGHT upon CreateWindowEx. (With the drawback of broken horizontal scrollbar in multine, like the VB.TextBox)
If none is true (W2K and WXP both False) the current way would be applied without quirks.
Re: CommonControls (Replacement of the MS common controls)
Just wondering, but why still support XP and W2K? who is using that for actual production with new software, even just to support the old legacy applications? I'm a VB6 developer, but we also don't support anything official below Windows 10 anymore, if it works, OK, if it doesn't that's your problem as you should have updated to a newer version of windows by now (we're a payrol application, we also have a 'modern' cloud based version now).
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by SuperDre
Just wondering, but why still support XP and W2K? who is using that for actual production with new software, even just to support the old legacy applications? I'm a VB6 developer, but we also don't support anything official below Windows 10 anymore, if it works, OK, if it doesn't that's your problem as you should have updated to a newer version of windows by now (we're a payrol application, we also have a 'modern' cloud based version now).
In principle I agree that it makes most sense to only support the Windows versions that Microsoft still supports. As a matter of fact, I've heard the same rationale about stopping to use a development tool that is from 1998...
But in reality there are many companies that lag behind in upgrading, often enough the larger ones and governments, given the costs of replacing hardware since existing PCs often are not strong enough for the newer OS. I hear from my business partners in Asia that there still quite a few companies use XP, and I even saw an XP-based PC hooked up to training equipment at a physio therapist in Belgium last year.
I'm facing a similar question/discussion when clients/prospects "demand" that my single user Windows desktop application works being shared by multiple users in a network, or on Citrix or Remote Desktop solutions. At some point is becomes a commercial decision between costs and opportunities.
Re: CommonControls (Replacement of the MS common controls)
Update released for TextBoxW control.
Originally Posted by Erwin69
In principle I agree that it makes most sense to only support the Windows versions that Microsoft still supports. As a matter of fact, I've heard the same rationale about stopping to use a development tool that is from 1998...
But in reality there are many companies that lag behind in upgrading, often enough the larger ones and governments, given the costs of replacing hardware since existing PCs often are not strong enough for the newer OS. I hear from my business partners in Asia that there still quite a few companies use XP, and I even saw an XP-based PC hooked up to training equipment at a physio therapist in Belgium last year.
I'm facing a similar question/discussion when clients/prospects "demand" that my single user Windows desktop application works being shared by multiple users in a network, or on Citrix or Remote Desktop solutions. At some point is becomes a commercial decision between costs and opportunities.
I did find a compromise now.. I really did not want to have a new overhead with some quirks...
So ES_LEFT/ES_CENTER/ES_RIGHT works now in Windows XP as it is supplied directly in dwStyle for CreateWindowEx.
However, changing the Alignment in code (run-time) is only working as of Windows Vista. (usage of SetWindowLong remains)
Of course when having vbCenter set as design-time the horizontal scrollbar is broken now. (if multiline = true and scrollbars set accordingly)
Workaround for that quirk would be to have vbLeftJustify at design-time and set at run-time (per code) the alignment to vbCenter, for instance.
Re: CommonControls (Replacement of the MS common controls)
Update released for the StatusBar control.
Originally Posted by Erwin69
#4. Both MS and VBCCR statusbars have been set up with 5 panels with widths of respectively 2000, 1275, 1440, 2000, and 2000. On initial load, the panels in both statusbars are aligned, but as soon as the form is resized, the VBCCR panels 2 and 3 are given widths that are too large.
You could have defined panels 2 and 3 as autosize spring to solve the issue. However, I did not give the tip to you as it should also work as you did. (manually defining the "spring width")
The research took longer as I assumed a bug in a logic but to no avail. The logic was correct.
At the end it just turned out that there was a reporting bug in Width (Property Get) of a Panel which you use in your Form to do the math.
I also detected a bug in the Left (Property Get) of a Panel. (did not affect you actually, but maybe others)
Thank you. Your points actually resulted in improvements.
Re: CommonControls (Replacement of the MS common controls)
Hello.
Congratolations with that project. I'm new using that ocx. I'm adapting a vb project with that ocx but I see that have a lot of differences and doubts. Hope you can help me...
I use the treeview and when I select one node, my script check on the database (is via remote TCP-IP) and insert new childrens on the selected node but what is strange is that the treeview not shows it automatically. I need to click again on the same node for show the childrens. I fixed that executing the command treeview.refresh or treeview.redraw just right after insert the childrens. It works but it's normal? Doesn't exists nothing better?
Code:
Private Sub TreeView_NodeClick(ByVal Node As TvwNode, ByVal Button As Integer)
FRM.LVAlert.Visible = False
If TCP_NotConnected Then Exit Sub
textExplorer.Text = Node.FullPath & "\"
textExplorer.Tag = Node.Key
If Node.Tag = "" Then
'Faz busca de pastas ao cliente
TCP.SendData EXPLORER_Folders & vbAA & textExplorer.Text & vbAABB
Node.Tag = True
Else
'Faz busca de ficheiros ao cliente
TCP.SendData EXPLORER_Files & vbAA & textExplorer.Text & vbAABB
lvFicheiros.ListItems.Clear
End If
Node.BackColor = &H6D6D6D
lvFicheiros.BackColor = &H80000018
End Sub
And Insert here:
Code:
....
If Right$(Data_Received, 1) <> vbBB Then Exit Sub
s = Split(Data_Received, vbAA)
Data_Received = vbNullString
lvFicheiros.ListItems.Clear
For x = 1 To UBound(s) - 1
TreeView.Nodes.Add textExplorer.Tag, tvwChild, "K" & treeKEY, s(x)
treeKEY = treeKEY + 1
Next x
TCP.SendData EXPLORER_Files & vbAA & textExplorer.Text & vbAABB
TreeView.Redraw = True
....
Other thing:
Any click anywhere on the treeview it calls the Sub TreeView_NodeClick! But I just want accept any click when really have selected the inside of node and not outside... How can I solve this?
Also, the variable treeview.node.checked (true or false) just can change when the checkbox is enable. But with the treeview from microsoft I used it as variavel for certain intern information and not for the user. So I don't wanna see the check box at left of the node, but use it internal. But not showing the check box, it node.checked, will be all the time false and if I try change it node.checked=true, I get an error... Can I change that for use it ?
And last, the SCroll= true in design mode, shows the scroll in the treeview but all the time I open a node (clicking on +) other node close automatically... If I put scroll=false, then I can open all nodes (not close automatically) but not shows the scroll.
I must say that the program already worked for long time withe the treeview microsoft ocx.
Hope you all understand and can help. Sorry my english is not good! Thank you
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
Update released for the StatusBar control.
You could have defined panels 2 and 3 as autosize spring to solve the issue. However, I did not give the tip to you as it should also work as you did. (manually defining the "spring width")
The research took longer as I assumed a bug in a logic but to no avail. The logic was correct.
At the end it just turned out that there was a reporting bug in Width (Property Get) of a Panel which you use in your Form to do the math.
I also detected a bug in the Left (Property Get) of a Panel. (did not affect you actually, but maybe others)
Thank you. Your points actually resulted in improvements.
Thanks Krool. There are so many options and improvements versus the MS common controls, and also some small but important changes, that converting an existing project is a challenge. (Especially if you're not a dedicated professional developer, like I am not.) I'm sure it will be easier when starting a project from scratch with your controls, or continuing after the full conversion.
One thing I found challenging is the fact that some controls have the same name as the "original" MS one. Another challenge was the fact that the Listview control doesn't take the column definitions in the IDE. (Unless I really missed something.) But all in all, the conversion went rather smoothly.
There is one thing left where I "struggled": my initial work to recreate the toolbar didn't work, as the images were not displaying correctly. So, I may post some questions about that in the future.
Re: CommonControls (Replacement of the MS common controls)
Hi.
I have a problem.
I have some script in that event TreeView_NodeSelect(ByVal Node As VBCCR17.TvwNode)... It is supposed execute just all the time I select a node, but the problem is that all the time I execute the treeview.nodes.clear, it clear all nodes but also executes the event above in the number of times it has items/nodes in the treeview ... It seems that the clear, deletes one by one, selecting the item next to the one that was deleted as if I had selected and triggers the event above ... And repeats this process until you delete all items!
How can I block the clear not triggering the above event?
Re: CommonControls (Replacement of the MS common controls)
Update released for the TreeView control.
Originally Posted by alcpf
Any click anywhere on the treeview it calls the Sub TreeView_NodeClick! But I just want accept any click when really have selected the inside of node and not outside... How can I solve this?
True. Strange that nobody noticed so far.
The NodeClick/NodeDblClick fired whenever TVM_HITTEST returned an hItem <> 0.
However, now it requires also the hit-test flags to be TVHT_ONITEMICON or TVHT_ONITEMLABEL. (like the MS TreeView does)
Originally Posted by alcpf
How can I block the clear not triggering the above event?
Well, as you said. The .Clear method will delete all items one by one.
The MS control has no exposed events for TVN_SELCHANGING/TVN_SELCHANGED so they did not care.
I updated the .Clear method now to set the caret item to NULL before sending the TVM_DELETEITEM.
The end result is the same (all items deleted and no caret item anymore either case).
But the change results now in no unnecessary TVN_SELCHANGING/TVN_SELCHANGED notifications.
Means no NodeSelect or NodeBeforeSelect events anymore when doing a .Clear.
In theory it should also speed up the .Clear.
Re: CommonControls (Replacement of the MS common controls)
Yes I thought strange too that nobody detected that.
Anyway I tested again with the new update and now works like a charme. Thank you very much
Just one thing that for me isn't a problem but can cause problems for others:
The event TreeView_Collapse is also called with the .clear, despite of your last changes! There was in fact no collapse and depending of what we write in that event, normally to prevent anything about the collapse, we will also have to program to prevent the effect of the .clear! The variable node gives the first item index (even if other was selected) that was before erased all, but the item will not be there anymore because .clear deleted all!
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by alcpf
And last, the SCroll= true in design mode, shows the scroll in the treeview but all the time I open a node (clicking on +) other node close automatically... If I put scroll=false, then I can open all nodes (not close automatically) but not shows the scroll.
Re: CommonControls (Replacement of the MS common controls)
Hey
I checked the first post and also GitHub but found no answer to these questions, could you please clarify:
1. What is the difference between VBCCR16 and 17?
2. What is the upgrade procedure when using the ActiveX version?
Note to point 1: unfortunately git commit messages are not being used, VBCCR/ActiveX Control Version/List of revisions.txt contains no meaningful info, and VBCCR/Standard EXE Version/List of revisions.txt jumps from 18-Aug-2020 to 23-Sep-2020 with no mention of the major version change from VBCCR16 to 17. Yes I do see the individual changes, but don't get what prompted a major change in version.
Note to point 2: I am aware of MountainMan's tool, good work, but I'm asking for a human explanation of what changed and how to migrate. I don't feel safe running a third-party tool over my code and would rather change things myself.
Re: CommonControls (Replacement of the MS common controls)
Krool,
How do I catch a mouse scroll inside the RichTextBox? I want to zoom in/out on a muse scroll when the user has the Ctrl key down. I looked through all of the events raised by the RichTextBox control and none look like they do what I want to do. Thanks.
Re: CommonControls (Replacement of the MS common controls)
I have an question regarding the RichTextBox. When I use .SelTextSize, .SelBold, .SelItalic and/or .SelUnderline at the end of the data already in the control, all of these effects revert back to normal as soon as a CrLf is input at that point. For example, if I have set the .SelBold property and then I send the string "How now" & vbCrLf & "brown cow" to the control, the text "How now" is bolded but then "brown cow" is not. Is that the intended behavior?
Re: CommonControls (Replacement of the MS common controls)
While I am on a roll with questions, what about VBA? I know your OCX file won't work with 64-bit VBA but I think at least some of the controls will work with VBA Do you know which ones do work with 32-bit VBA? Also, other than trying out each one and seeing which ones lock up or crash the machine, how can you tell which ones will or will not work with VBA?
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by MountainMan
How do I catch a mouse scroll inside the RichTextBox? I want to zoom in/out on a muse scroll when the user has the Ctrl key down. I looked through all of the events raised by the RichTextBox control and none look like they do what I want to do. Thanks.
For me it works without additional code.
Another story is Ctrl and +/-.
Then you need this:
Code:
Private Function SetZoom(ByVal ZoomRatio As Long)
Dim Numerator As Long
Dim Denominator As Long
Static inProc As Boolean
'--------------------------------------------------
If inProc Then Exit Function Else inProc = True
If ZoomRatio < 10 Or ZoomRatio > 500 Then Exit Function
If ZoomRatio = 100 Then
Numerator = 0
Denominator = 0
Else
If ZoomRatio < 100 Then
Numerator = ZoomRatio
Denominator = 100
Else
Numerator = ZoomRatio / 1.960784
Denominator = 51
End If
End If
Call SendMessage(RTF.hwnd, EM_SETZOOM, ByVal Numerator, ByVal Denominator)
inProc = False
End Function
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by OldClock
I checked the first post and also GitHub but found no answer to these questions, could you please clarify:
1. What is the difference between VBCCR16 and 17?
2. What is the upgrade procedure when using the ActiveX version?
Note to point 1: unfortunately git commit messages are not being used, VBCCR/ActiveX Control Version/List of revisions.txt contains no meaningful info, and VBCCR/Standard EXE Version/List of revisions.txt jumps from 18-Aug-2020 to 23-Sep-2020 with no mention of the major version change from VBCCR16 to 17. Yes I do see the individual changes, but don't get what prompted a major change in version.
Note to point 2: I am aware of MountainMan's tool, good work, but I'm asking for a human explanation of what changed and how to migrate. I don't feel safe running a third-party tool over my code and would rather change things myself.
The process is this:
The Std-EXE version is the leading source. So the list of revision contains everything for it.
From time to time (in the past maybe every year or so) the latest state was bundled into a OCX.
Further bugfixes are integrated into the OCX, BUT new features weren't to not break binary compatibility.
So the difference between VBCCR16 and 17 is basically bigger. (1 year or so of new features)
To note is, when now bugs gets fixed it will only be fixed in VBCCR17. (VBCCR16 not supported anymore)
So, it might be better to switch to version 17. I basically do not plan to introduce new features, so 17 might be the last version.
However, bugfixes will be done as long as possible.
You can upgrade manually. Replacing the in the .vbp and all .frm files manually (via text editor) from 16 to 17.
Originally Posted by MountainMan
While I am on a roll with questions, what about VBA? I know your OCX file won't work with 64-bit VBA but I think at least some of the controls will work with VBA Do you know which ones do work with 32-bit VBA? Also, other than trying out each one and seeing which ones lock up or crash the machine, how can you tell which ones will or will not work with VBA?
The VBFlexGrid OCX works best in VBA as it supports accelerator keys in a VBA environment. (PreTranslateMsg function implemented)
The VBCCR OCX does not (yet) support accelerator keys. However, it is tested that they at least not crash when placed in a UserForm.
Originally Posted by MountainMan
How do I catch a mouse scroll inside the RichTextBox? I want to zoom in/out on a muse scroll when the user has the Ctrl key down. I looked through all of the events raised by the RichTextBox control and none look like they do what I want to do. Thanks.
The Scroll event is not good for you need as it works only when the RichTextBox scrolls the content.
What you need is actually a WM_MOUSEWHEEL handler.
So, just subclass the RichTextBox control and handle WM_MOUSEWHEEL accordingly.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
So, just subclass the RichTextBox control and handle WM_MOUSEWHEEL accordingly.
But it works as wanted without doing ANYTHING...
Ctrl held down + mousewheel action zooms the viewport, as in the very most programs.
Seems I misunderstand the wish?
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Karl77
But it works as wanted without doing ANYTHING...
Ctrl held down + mousewheel action zooms the viewport, as in the very most programs.
Seems I misunderstand the wish?
You are absolutely correct. Duh. I never checked that. I assumed it wouldn't do that automatically and I didn't see where anyone had brought it up in this thread so I was looking for the code to do it. Your observation makes life simpler. Thanks.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by OldClock
Hey
I checked the first post and also GitHub but found no answer to these questions, could you please clarify:
1. What is the difference between VBCCR16 and 17?
2. What is the upgrade procedure when using the ActiveX version?
Note to point 2: I am aware of MountainMan's tool, good work, but I'm asking for a human explanation of what changed and how to migrate. I don't feel safe running a third-party tool over my code and would rather change things myself.
In the .vbp file you have to change the reference and the GUID for the .OCX.
In each of the .frm files you have to change the reference for the .OCX at the top of the file and GUID for each instance of each control that you use.
If you use a resource file that includes a manifest, you have to edit that to change the references to the .OCX and all of the controls. Note that Krool has added some new controls so you have to know which ones he added and change those references too. I find manually editing the guts of a manifest file to be cumbersome so in my utility I borrowed some of LaVolpe's code from his Manifest Creator program to open, find the old references and save the manifest with the new references.
You may have references to controls in .bas or .cls modules to controls within the .ocx (no GUID's) so the references must be changed also.
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
How is the SingleSel property set?
Singlesel was set as true!!!! I changed and it works as I want! I checked almost all definitions and I don't know how missed this one!
Thank you
About the columnheader I can change the forecolor but I don't found the backcolor!
I wrote this:
lvFiles.ColumnHeaders.Add(, , "Type", 600, LvwColumnHeaderAlignmentRight).ForeColor = &HFF
I want change the backcolor for slightly more or less dark than the body of the listview and the text white!
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by alcpf
About the columnheader I can change the forecolor but I don't found the backcolor!
This feature is not in-built included as it requires complete owner-drawing of the header items.
So, you can implement it but it requires some homework.
I can give you the starting point.
Subclass the ListView.hWnd and intercept the WM_DRAWITEM message.
Code:
Private Function WindowProcControl(ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
If wMsg = WM_DRAWITEM Then
Dim DIS As DRAWITEMSTRUCT
CopyMemory DIS, ByVal lParam, LenB(DIS)
' DIS.CtlType has undocumented &H64. Better to not rely on that.
If DIS.hWndItem = ListView1.hWndHeader Then
' DIS.ItemID is the column index
Dim Brush As Long
Brush = CreateSolidBrush(vbBlue)
FillRect DIS.hDC, DIS.RCItem, Brush
DeleteObject Brush
' Background now filled. Now need to paint the rest...
WindowProcControl = 1
Exit Function
End If
End If
[...]
But you need to do something in order to get WM_DRAWITEM.
Code:
Private Const LVCFMT_COL_HAS_IMAGES As Long = &H8000& ' Same as HDF_OWNERDRAW
This flag you need to set. You can only make 1 particular column header owner-drawn or all one-by-one so every column header is owner-drawn.
Below code will make column header 1 owner-drawn. For example if Index is 1.
Code:
Dim LVC As LVCOLUMN
With LVC
.Mask = LVCF_FMT
SendMessage ListView1.hWnd, LVM_GETCOLUMN, Index - 1, ByVal VarPtr(LVC)
.fmt = .fmt Or LVCFMT_COL_HAS_IMAGES
SendMessage ListView1.hWnd, LVM_SETCOLUMN, Index - 1, ByVal VarPtr(LVC)
End With
Re: CommonControls (Replacement of the MS common controls)
Two additional questions:
1. Is the date/time picker supposed to pick up localized words for Today, the months and the days? If so, how is the language selected? Windows regional settings?
2. When using the standard common controls, I get the "modern Win10" file open dialog. With my first attempt with the CCR common dialog I get this small, really old looking dialog. Am I doing something wrong?
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Erwin69
Two additional questions:
1. Is the date/time picker supposed to pick up localized words for Today, the months and the days? If so, how is the language selected? Windows regional settings?
2. When using the standard common controls, I get the "modern Win10" file open dialog. With my first attempt with the CCR common dialog I get this small, really old looking dialog. Am I doing something wrong?
1.
I think it is tied to the regional settings.
2.
Be sure that .HookEvents is False. Otherwise you get the Win 3.1 style open dialog.
Or what do you mean with small old looking ? Maybe post a screenshot to explain it better..
Re: CommonControls (Replacement of the MS common controls)
Hi Krool,
Exists a way of the node parent not stay so far from the left treeview box border? The indentation as I know it's just for the distance of the child relative it's parent... Because I have the treeview without border into a picturesbox, I can fix making something like treeview.left -120 and will cut the gap between the treeview border and the node but maybe you know something better! See the image:
Other thing. I added an imagelist to the threeview with 16px icons... But if I write a key to identify the icon, when I apply the custom panel(design mode), it simply change the pixels automatically for 32px and don't let me go back again even if I delete the key of the image... I need to delete all images and add again... But not accept the key otherwise happens again what I said. The unique way was using the index, but it's a mess if I add a lot of images and I can't add in the middle of the others because will reorganize the index order and I need to change everywhere in the list where I use the index images... The behavior of the key above was did by some reason or it's a bug? Or maybe could be a problem of my VB6 editor!!!!
Re: CommonControls (Replacement of the MS common controls)
Hi krool
In listview , Underlining hot item works only when moving by mouse vertically (In the same column) . If I move mouse horizontally (Within the same row) , it is not then changed .
Last edited by Hosam AL Dein; Mar 6th, 2021 at 01:15 AM.
Re: CommonControls (Replacement of the MS common controls)
Issue: Toolbar control changing size properties without user action
Forgive if this has already been discussed (but I did not find any reference in the thread). I have a few projects using the VBCCR controls, and have found that certain forms want to be updated and saved by VB6 when there has been no change to the form. All that is needed to cause this is to open the form (either Code or Object) and then close it. Even a search that touches the code in the form will cause this. I have tracked it down to the Toolbar (and its button) width and height properties changing. (I made files before and after touching the form to look for changes.) There does not appear to be any functional issues with this, but it causes any form to want to be re-saved even when there have been no changes, and it always makes me go back and check it I have accidentally updated anything.
Note that none of the other controls that I have used (TextboxW, LabelW, CommandButtonW) are showing this behavior. Thanks for your help (as always)!
Re: CommonControls (Replacement of the MS common controls)
Originally Posted by Krool
1.
I think it is tied to the regional settings.
2.
Be sure that .HookEvents is False. Otherwise you get the Win 3.1 style open dialog.
Or what do you mean with small old looking ? Maybe post a screenshot to explain it better..
It took a while to get the feedback for #1, but I can confirm it is indeed linked to the regional settings.
As for #2, it was indeed the HookEvents setting. The small, old looking dialog that I mentioned, was indeed the Win 3.1 style dialog. Too long ago for me to remember it looked like that back in the days... ;-)
Re: CommonControls (Replacement of the MS common controls)
I'm wondering if I will add the option of giving the user the choice between two sizes toolbar buttons. Let's say one based on 16x16 buttons, another based on 32x32.
What would be the best way to do that? Create two toolbars, and switch the visual property on/off? Stick to one toolbar, and change imagelist during runtime depending on the user's choice?