[[Delphius]]

Hola nuevamente.

thelibmx disculpa si no me di a entender. La primera versión no te anda porque tienes declarado como variable un Combo que en ningún momento fue creado para reservarle memoria. El compilador no protesta cuando le pones Combo.propiedad := algo pero en el momento de ejecución cuando intenta acceder a la zona de memoria destinada para dicho combo se da con que no existe. Por lo tanto protesta arrojandote el error. La solución:
1. Crearlo.
2. Operar con el
3. Mostrarlo, fue creado pero no está visible. Hay que darle un lugar donde mostrarlo.

Una opción (muy simple por cierto) para conseguir esto es la que doy a continuación, basada en tu código. No la he probado, la escribí a mano... no tengo Delphi a mano. Debería andar.
Hice el supuesto que la forma en donde estará el combo se llama form1.

Código Delphi [-]
procedure llenadocombo;
var
Count1,pos: integer;
text: string;
comboxselectoranio:tcombobox;
begin
// para que te funcione la variable es necesario primero reservar memoria:
// como ejemplo hice que sea Form1 el "dueño" del Combo, Form1 se encargará
// de liberar la memoria de Combo
 comboxselectoranio := TComboBox.Create(Form1);

//llenado de combo box de años de quincena
    Pos := ComBoxselectoranio.SelStart;
    ComBoxselectoranio.Items.Clear;
    Text := ComBoxselectoranio.Text;
formconecciones.Query_catalogo_quincenasmod.Close;
formconecciones.Query_catalogo_quincenasmod.SQL.Clear;
formconecciones.Query_catalogo_quincenasmod.SQL.Add('select distinct anio from catalogo_quincenas');
formconecciones.Query_catalogo_quincenasmod.ExecSQL;
formconecciones.Query_catalogo_quincenasmod.Open;
 Count1:=formconecciones.Query_catalogo_quincenasmod.RowsAffected;
  showmessage(inttostr(count1));
    if Count1 > 0 then
     begin
      repeat Dec(Count1);
      ComBoxselectoranio.Items.Add(formconecciones.Query_catalogo_quincenasmod.FieldByName('anio').AsStrin  g);
       formconecciones.Query_catalogo_quincenasmod.Next;
      until Count1 = 0;
      ComBoxselectoranio.ItemIndex := 0;
      ComBoxselectoranio.SelStart := Pos;
      ComBoxselectoranio.SelLength := 255;
    end;
//llena combobox año  de quincena

 // Lo hago visible, es decir lo muestro...
 // Lo correcto sería indicarle la posición
 comboxselectoranio.Parent := Form1;
end;

Ahora, esto es una opinión mia. En lo preferente evito estar declarando objetos visuales, crearlos y mostrarlos como el código que puse. Esto reduce la utilización, ya que hace en el código mismo se hace la asignación del dueño del componente. Con lo cual se forma una dependencia entre el procedimiento y la forma "dueña".

Esta relación puede romperse. Esto se consigue con la segunda versión del procedimiento, la que recibe el parámetro. Esto favorece la reutilización ya que se ha desplazado la responsabilidad de asignar el "dueño" a otro; el procedimiento solamente se encarga de llenarlo, de "quien" es el combo... no le incumbe. Que se consigue, esto:

Código Delphi [-]
LlenarCombo(form1.ComboAños);
LlenarCombo(form2.MiCombo);

¿Ves la diferencia? Ahora LlenarCombo puede ser usado en cualquier lado... bueno... no tanto... todavía mantiene otra dependencia: formconecciones. Podemos mejorarlo. Hacerlo que ya no dependa de un form para acceder a un TQuery. ¿Porqué no hacerlo que lo haga de un DataModule y desplazar la dependencia hacia la capa de datos, que es donde probablemente mayor sentido tiene? O mejor aún... dejamos que LlenarCombo sea de la capa lógica... que no "dependa" de ni la capa de interfaz ni la de la capa de datos? ¿Como hacer esto?

Código Delphi [-]
procedure LlenarCombo(Combo: TComboBox; Desde: TQuery);

Este procedimiento no debería encargarse de lanzar la consulta. Sólo debería recorrer los registros devueltos por la consulta, lanzada en un momento anterior y llenar el combo.

Con esto en mente se puede hacer algo como esto:

Código Delphi [-]
LlenarCombo(Form1.ComboAnio, DM1.QueryAnio);

Ahora si esta lindo, limpio. Un procedimiento que no está declarado en ningún form, puede que incluso fuera del DataModule... está en la capa lógica, en una unidad ULimpieza si se quiere.

Habrás notado que dije anteriormente "no dependa". Esto no es totalmente posible. SIEMPRE existe dependencia, podemos reducir el "ruido" entre las dependencias pero no eliminarlo. Un objeto (función, procedimiento, units, etc) que no mantenga dependencia tiene dos defectos:
1. No sabe designar responsabilidades y hace todo el trabajo por si mismo. O bien...
2. A sido mal diseñado e implementado. Ya que no sabe para quien debe "trabajar".

thelibmx me alegro serte de ayuda, pero sigue mi consejo. No te quedes con lo simple que te comenté. Hay varias maneras de llevar un trabajo modular... lo que expuse es una filosofía que he desarrollado y como filosofía no es totalmente certera ni abosulta. Muy seguramente hay otras personas que también tienen otro punto de vista y distinta manera de ver las cosas.

Recuerda esto también: antes de llevar a cabo la modularización debes saber manejar e imponer un precio al tamaño de esto. Debes saber que un buen sistema modular no debe tener demasiado módulos, pero tampoco muy pocos. ¿Cuanto es demasiado?¿Cuanto es muy poco? Tu sabrás, dependiendo de la naturaleza del problema, de los requisitos y el sentido común hasta donde llegarás para decidir que va en un módulo, que va en otro... Esto no es ciencia exacta, lamentablemente (aunque para mi es lo que hace lindo a la informática)

Saludos,